[OE-core] [PATCH] core-image-sato-sdk: test image with 512M memory

ChenQi Qi.Chen at windriver.com
Mon Aug 19 09:14:11 UTC 2019


On 08/16/2019 02:53 PM, Kang Kai wrote:
> On 2019/8/12 下午4:57, Kang Kai wrote:
>> On 2019/7/27 下午4:42, Kang Kai wrote:
>>> On 2019/7/27 上午5:40, richard.purdie at linuxfoundation.org wrote:
>>>> On Fri, 2019-07-26 at 05:23 -0400, kai.kang at windriver.com wrote:
>>>>> From: Kai Kang <kai.kang at windriver.com>
>>>>>
>>>>> When run do_testimage for core-image-sato-sdk, it fails to pass test
>>>>> case:
>>>>>
>>>>>> RESULTS - systemd.SystemdBasicTests.test_systemd_failed: FAILED
>>>>>> (0.43s)
>>>>> It is OOM issue and daemon rpc.statd is killed:
>>>>>
>>>>>>   [  531.306146] Out of memory: Kill process 193 (rpc.statd) score
>>>>>> 200 or sacrifice child
>>>>> Increase the memory of qemu to 512M to avoid such OOM issue.
>>>>>
>>>>> Signed-off-by: Kai Kang <kai.kang at windriver.com>
>>>>> ---
>>>>>   meta/recipes-sato/images/core-image-sato-sdk.bb | 1 +
>>>>>   1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/meta/recipes-sato/images/core-image-sato-sdk.bb
>>>>> b/meta/recipes-sato/images/core-image-sato-sdk.bb
>>>>> index d7cc52b52b..f7963d018e 100644
>>>>> --- a/meta/recipes-sato/images/core-image-sato-sdk.bb
>>>>> +++ b/meta/recipes-sato/images/core-image-sato-sdk.bb
>>>>> @@ -9,3 +9,4 @@ IMAGE_FEATURES += "dev-pkgs tools-sdk \
>>>>>     IMAGE_INSTALL += "kernel-devsrc"
>>>>>   +TEST_QEMUPARAMS = "-m 512"
>>>> Any idea what is using so much memory in the image when this happens?
>>>>
>>>> Its rather sad that we can't have NFS+systemd with 256MB memory...
>>>
>>> It caused by stap test case. I minimized the test cases to
>>>
>>> TEST_SUITES = "ping date ssh systemd stap kernelmodule gcc "
>>>
>>> which could reproduce the error.
>>>
>>> And it PASSes testimage that remove stap test from default TEST_SUITES:
>>>
>>> TEST_SUITES_remove = 'stap'
>>>
>>> But I can't reproduce the OOM failure to run stap tests manually.
>>
>> Hi Richard,
>>
>> The root cause of test case stap fails is available memory is too 
>> low. Compare systemd with sysvinit, memory status are listed:
>>
>> systemd:
>> root at qemux86:~# free -h
>>               total        used        free      shared buff/cache   
>> available
>> Mem:          239Mi       120Mi        23Mi       8.0Mi 94Mi 100Mi
>> Swap:            0B          0B          0B
>>
>> sysvinit:
>> root at qemux86:~# free -h
>>               total        used        free      shared buff/cache   
>> available
>> Mem:          239Mi        45Mi       111Mi       0.0Ki 82Mi 184Mi
>> Swap:            0B          0B          0B
>>
>>
>> With systemd, processes of rpc.statd and rpc.mountd take about less 
>> than 80M memories.
>> And I compared with Debian 10, they take similar size of memories.
>>
>> PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM TIME+ COMMAND
>> 464 rpcuser   20   0   56316  51336   2192 S   0.0  20.9 0:00.09 
>> rpc.statd
>>   186 root      20   0   30136  27024   2280 S   0.0  11.0 0:00.02 
>> rpc.mountd
>>
>>
>> Compare to sysvinit, they take only about 2M and 448K:
>>
>>  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM TIME+ COMMAND
>>   567 rpcuser   20   0    3444   2372   1792 S   0.0   1.0 0:00.00 
>> rpc.statd
>>   677 root      20   0    3700    448      0 S   0.0   0.2 0:00.00 
>> rpc.mountd
>>
>>
>> I didn't figure out the differences between these 2 ways to start the 
>> commands:
>>
>> ExecStart=/usr/sbin/rpc.statd -F $STATD_OPTS
>>
>> Vs.
>>
>> test -x "$NFS_STATD" || NFS_STATD=/usr/sbin/rpc.statd
>> start-stop-daemon --start --exec "$NFS_STATD" --pidfile "$STATD_PID"
>
> Hi Richard,
>
> Any more comment here please?
>
> Regards,
> Kai
>
>

Hi Richard,

Do you think it's acceptable to use swap as part of this test case? For 
example, enable 100M swap before running `stap' and disable it 
afterwards? This ensure no oom caused by other software using too much 
memory.

Best Regards,
Chen Qi

>
>>
>>
>> Regards,
>> Kai
>>
>>
>>
>>
>>>
>>>
>>> Regards,
>>> Kai
>>>
>>>>
>>>> Cheers,
>>>>
>>>> Richard
>>>>
>>>>
>>>
>>
>



More information about the Openembedded-core mailing list