[PATCH] systemd: decreasing default RLIMIT_NOFILE on qemu bsp

[PATCH] systemd: decreasing default RLIMIT_NOFILE on qemu bsp

[Hongxu Jia]

Since do_testimage for core-image-sato-sdk has memory limitation (256Mib)
which caused rpc.statd failed with out of memory.
[  531.306146] Out of memory: Kill process 193 (rpc.statd) score 200 or sacrifice child

The rpc.statd allocates memory according to RLIMIT_NOFILE,
so decrease it to 4k to keep sync with sysvinit

After applying the patch, the memory cost is the same with sysvinit
rpcuser    340  0.0  1.0   3212  2588 ?        Ss   13:20   0:00 /usr/sbin/rpc.statd -F
root       473  0.0  0.2   3464   496 ?        Ss   13:23   0:00 /usr/sbin/rpc.mountd

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
---
 ...0001-decreasing-the-default-RLIMIT_NOFILE.patch | 35 ++++++++++++++++++++++
 meta/recipes-core/systemd/systemd_242.bb           |  4 +++
 2 files changed, 39 insertions(+)
 create mode 100644 meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch

diff --git a/meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch b/meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
new file mode 100644
index 0000000..fb8e2c9
--- /dev/null
+++ b/meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
@@ -0,0 +1,35 @@
+From 55c7196163e481c508fa708b9b8f5e7bf2d2f007 Mon Sep 17 00:00:00 2001
+From: Hongxu Jia <hongxu.jia@windriver.com>
+Date: Mon, 19 Aug 2019 07:16:47 -0400
+Subject: [PATCH] decreasing the default RLIMIT_NOFILE
+
+Since do_testimage for core-image-sato-sdk has memory limits (256Mib)
+which caused rpc.statd failed with out of memory.
+[  531.306146] Out of memory: Kill process 193 (rpc.statd) score 200 or sacrifice child
+
+The rpc.statd allocates memory according to RLIMIT_NOFILE,
+so decrease it to 4k which keep sync with sysvinit
+
+Upstream-Status: Inappropriate [oe specific]
+
+Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
+---
+ meson.build | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/meson.build b/meson.build
+index 18a7cc5..e30894b 100644
+--- a/meson.build
++++ b/meson.build
+@@ -79,7 +79,7 @@ conf.set10('HAVE_SYSV_COMPAT', sysvinit_path != '' and sysvrcnd_path != '',
+ 
+ conf.set10('BUMP_PROC_SYS_FS_FILE_MAX', get_option('bump-proc-sys-fs-file-max'))
+ conf.set10('BUMP_PROC_SYS_FS_NR_OPEN',  get_option('bump-proc-sys-fs-nr-open'))
+-conf.set('HIGH_RLIMIT_NOFILE',          512*1024)
++conf.set('HIGH_RLIMIT_NOFILE',          4*1024)
+ 
+ # join_paths ignores the preceding arguments if an absolute component is
+ # encountered, so this should canonicalize various paths when they are
+-- 
+2.8.1
+
diff --git a/meta/recipes-core/systemd/systemd_242.bb b/meta/recipes-core/systemd/systemd_242.bb
index 1953fef..ab15ad2 100644
--- a/meta/recipes-core/systemd/systemd_242.bb
+++ b/meta/recipes-core/systemd/systemd_242.bb
@@ -58,6 +58,10 @@ SRC_URI_MUSL = "file://0001-Use-getenv-when-secure-versions-are-not-available.pa
                file://0001-do-not-disable-buffer-in-writing-files.patch \
                "
 
+SRC_URI_append_qemuall = " \
+               file://0001-decreasing-the-default-RLIMIT_NOFILE.patch \
+"
+
 PAM_PLUGINS = " \
     pam-plugin-unix \
     pam-plugin-loginuid \
-- 
2.8.1

Re: [PATCH] systemd: decreasing default RLIMIT_NOFILE on qemu bsp

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 4058 bytes --]

Should the limit be simply raised? The 256M setup is crumbling on several
fronts (runtime tests, modernisation of X, various non-x86 qemu targets).
Adding per-image/target exceptions, custom non-upstreamable patches, or
sticking to deprecated configurations isn't the right thing to do, I think.

Alex

On Mon, 19 Aug 2019 at 15:34, Hongxu Jia <hongxu.jia@windriver.com> wrote:

> Since do_testimage for core-image-sato-sdk has memory limitation (256Mib)
> which caused rpc.statd failed with out of memory.
> [  531.306146] Out of memory: Kill process 193 (rpc.statd) score 200 or
> sacrifice child
>
> The rpc.statd allocates memory according to RLIMIT_NOFILE,
> so decrease it to 4k to keep sync with sysvinit
>
> After applying the patch, the memory cost is the same with sysvinit
> rpcuser    340  0.0  1.0   3212  2588 ?        Ss   13:20   0:00
> /usr/sbin/rpc.statd -F
> root       473  0.0  0.2   3464   496 ?        Ss   13:23   0:00
> /usr/sbin/rpc.mountd
>
> Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
> ---
>  ...0001-decreasing-the-default-RLIMIT_NOFILE.patch | 35
> ++++++++++++++++++++++
>  meta/recipes-core/systemd/systemd_242.bb           |  4 +++
>  2 files changed, 39 insertions(+)
>  create mode 100644
> meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
>
> diff --git
> a/meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
> b/meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
> new file mode 100644
> index 0000000..fb8e2c9
> --- /dev/null
> +++
> b/meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
> @@ -0,0 +1,35 @@
> +From 55c7196163e481c508fa708b9b8f5e7bf2d2f007 Mon Sep 17 00:00:00 2001
> +From: Hongxu Jia <hongxu.jia@windriver.com>
> +Date: Mon, 19 Aug 2019 07:16:47 -0400
> +Subject: [PATCH] decreasing the default RLIMIT_NOFILE
> +
> +Since do_testimage for core-image-sato-sdk has memory limits (256Mib)
> +which caused rpc.statd failed with out of memory.
> +[  531.306146] Out of memory: Kill process 193 (rpc.statd) score 200 or
> sacrifice child
> +
> +The rpc.statd allocates memory according to RLIMIT_NOFILE,
> +so decrease it to 4k which keep sync with sysvinit
> +
> +Upstream-Status: Inappropriate [oe specific]
> +
> +Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
> +---
> + meson.build | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/meson.build b/meson.build
> +index 18a7cc5..e30894b 100644
> +--- a/meson.build
> ++++ b/meson.build
> +@@ -79,7 +79,7 @@ conf.set10('HAVE_SYSV_COMPAT', sysvinit_path != '' and
> sysvrcnd_path != '',
> +
> + conf.set10('BUMP_PROC_SYS_FS_FILE_MAX',
> get_option('bump-proc-sys-fs-file-max'))
> + conf.set10('BUMP_PROC_SYS_FS_NR_OPEN',
> get_option('bump-proc-sys-fs-nr-open'))
> +-conf.set('HIGH_RLIMIT_NOFILE',          512*1024)
> ++conf.set('HIGH_RLIMIT_NOFILE',          4*1024)
> +
> + # join_paths ignores the preceding arguments if an absolute component is
> + # encountered, so this should canonicalize various paths when they are
> +--
> +2.8.1
> +
> diff --git a/meta/recipes-core/systemd/systemd_242.bb
> b/meta/recipes-core/systemd/systemd_242.bb
> index 1953fef..ab15ad2 100644
> --- a/meta/recipes-core/systemd/systemd_242.bb
> +++ b/meta/recipes-core/systemd/systemd_242.bb
> @@ -58,6 +58,10 @@ SRC_URI_MUSL =
> "file://0001-Use-getenv-when-secure-versions-are-not-available.pa
>                 file://0001-do-not-disable-buffer-in-writing-files.patch \
>                 "
>
> +SRC_URI_append_qemuall = " \
> +               file://0001-decreasing-the-default-RLIMIT_NOFILE.patch \
> +"
> +
>  PAM_PLUGINS = " \
>      pam-plugin-unix \
>      pam-plugin-loginuid \
> --
> 2.8.1
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 5501 bytes --]

Re: [PATCH] systemd: decreasing default RLIMIT_NOFILE on qemu bsp

[Hongxu Jia]

[-- Attachment #1: Type: text/plain, Size: 5519 bytes --]

On 8/19/19 10:01 PM, Alexander Kanavin wrote:
> Should the limit be simply raised? The 256M setup is crumbling on 
> several fronts (runtime tests, modernisation of X, various non-x86 
> qemu targets). Adding per-image/target exceptions, custom 
> non-upstreamable patches, or sticking to deprecated configurations 
> isn't the right thing to do, I think.
>
The modification of set default RLIMIT_NOFILE(4k) just keeps sync with 
the one in sysvinit,

if the fronts you mentioned are working fine on sysvinit, I think it 
should be OK on systemd

but whether it has side effect or not still depends on the result of 
image test


The fix is trying to fix the blocking issue while switching init manager 
from sysvinit to systemd for poky


Hi RP,

Should we make HIGH_RLIMIT_NOFILE configurable from local.conf?

Then we could modify it according to the requirement, such as set it to 
4k at image test

//Hongxu

>
> Alex
>
> On Mon, 19 Aug 2019 at 15:34, Hongxu Jia <hongxu.jia@windriver.com 
> <mailto:hongxu.jia@windriver.com>> wrote:
>
>     Since do_testimage for core-image-sato-sdk has memory limitation
>     (256Mib)
>     which caused rpc.statd failed with out of memory.
>     [  531.306146] Out of memory: Kill process 193 (rpc.statd) score
>     200 or sacrifice child
>
>     The rpc.statd allocates memory according to RLIMIT_NOFILE,
>     so decrease it to 4k to keep sync with sysvinit
>
>     After applying the patch, the memory cost is the same with sysvinit
>     rpcuser    340  0.0  1.0   3212  2588 ?        Ss   13:20  0:00
>     /usr/sbin/rpc.statd -F
>     root       473  0.0  0.2   3464   496 ?        Ss   13:23  0:00
>     /usr/sbin/rpc.mountd
>
>     Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com
>     <mailto:hongxu.jia@windriver.com>>
>     ---
>      ...0001-decreasing-the-default-RLIMIT_NOFILE.patch | 35
>     ++++++++++++++++++++++
>      meta/recipes-core/systemd/systemd_242.bb <http://systemd_242.bb>
>              |  4 +++
>      2 files changed, 39 insertions(+)
>      create mode 100644
>     meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
>
>     diff --git
>     a/meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
>     b/meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
>     new file mode 100644
>     index 0000000..fb8e2c9
>     --- /dev/null
>     +++
>     b/meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
>     @@ -0,0 +1,35 @@
>     +From 55c7196163e481c508fa708b9b8f5e7bf2d2f007 Mon Sep 17 00:00:00
>     2001
>     +From: Hongxu Jia <hongxu.jia@windriver.com
>     <mailto:hongxu.jia@windriver.com>>
>     +Date: Mon, 19 Aug 2019 07:16:47 -0400
>     +Subject: [PATCH] decreasing the default RLIMIT_NOFILE
>     +
>     +Since do_testimage for core-image-sato-sdk has memory limits (256Mib)
>     +which caused rpc.statd failed with out of memory.
>     +[  531.306146] Out of memory: Kill process 193 (rpc.statd) score
>     200 or sacrifice child
>     +
>     +The rpc.statd allocates memory according to RLIMIT_NOFILE,
>     +so decrease it to 4k which keep sync with sysvinit
>     +
>     +Upstream-Status: Inappropriate [oe specific]
>     +
>     +Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com
>     <mailto:hongxu.jia@windriver.com>>
>     +---
>     + meson.build | 2 +-
>     + 1 file changed, 1 insertion(+), 1 deletion(-)
>     +
>     +diff --git a/meson.build b/meson.build
>     +index 18a7cc5..e30894b 100644
>     +--- a/meson.build
>     ++++ b/meson.build
>     +@@ -79,7 +79,7 @@ conf.set10('HAVE_SYSV_COMPAT', sysvinit_path !=
>     '' and sysvrcnd_path != '',
>     +
>     + conf.set10('BUMP_PROC_SYS_FS_FILE_MAX',
>     get_option('bump-proc-sys-fs-file-max'))
>     + conf.set10('BUMP_PROC_SYS_FS_NR_OPEN',
>     get_option('bump-proc-sys-fs-nr-open'))
>     +-conf.set('HIGH_RLIMIT_NOFILE',          512*1024)
>     ++conf.set('HIGH_RLIMIT_NOFILE',          4*1024)
>     +
>     + # join_paths ignores the preceding arguments if an absolute
>     component is
>     + # encountered, so this should canonicalize various paths when
>     they are
>     +--
>     +2.8.1
>     +
>     diff --git a/meta/recipes-core/systemd/systemd_242.bb
>     <http://systemd_242.bb> b/meta/recipes-core/systemd/systemd_242.bb
>     <http://systemd_242.bb>
>     index 1953fef..ab15ad2 100644
>     --- a/meta/recipes-core/systemd/systemd_242.bb <http://systemd_242.bb>
>     +++ b/meta/recipes-core/systemd/systemd_242.bb <http://systemd_242.bb>
>     @@ -58,6 +58,10 @@ SRC_URI_MUSL =
>     "file://0001-Use-getenv-when-secure-versions-are-not-available.pa
>     <http://available.pa>
>     file://0001-do-not-disable-buffer-in-writing-files.patch \
>                     "
>
>     +SRC_URI_append_qemuall = " \
>     +  file://0001-decreasing-the-default-RLIMIT_NOFILE.patch \
>     +"
>     +
>      PAM_PLUGINS = " \
>          pam-plugin-unix \
>          pam-plugin-loginuid \
>     -- 
>     2.8.1
>
>     -- 
>     _______________________________________________
>     Openembedded-core mailing list
>     Openembedded-core@lists.openembedded.org
>     <mailto:Openembedded-core@lists.openembedded.org>
>     http://lists.openembedded.org/mailman/listinfo/openembedded-core
>


[-- Attachment #2: Type: text/html, Size: 8933 bytes --]

Re: [PATCH] systemd: decreasing default RLIMIT_NOFILE on qemu bsp

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 5115 bytes --]

Probably in this case it is better to add a patch that allows
HIGH_RLIMIT_NOFILE to be configured from the systemd recipe via meson
switches, and offer that to systemd upstream.

Alex

On Mon, 19 Aug 2019 at 16:25, Hongxu Jia <hongxu.jia@windriver.com> wrote:

> On 8/19/19 10:01 PM, Alexander Kanavin wrote:
>
> Should the limit be simply raised? The 256M setup is crumbling on several
> fronts (runtime tests, modernisation of X, various non-x86 qemu targets).
> Adding per-image/target exceptions, custom non-upstreamable patches, or
> sticking to deprecated configurations isn't the right thing to do, I think.
>
> The modification of set default RLIMIT_NOFILE(4k) just keeps sync with the
> one in sysvinit,
>
> if the fronts you mentioned are working fine on sysvinit, I think it
> should be OK on systemd
>
> but whether it has side effect or not still depends on the result of image
> test
>
>
> The fix is trying to fix the blocking issue while switching init manager
> from sysvinit to systemd for poky
>
>
> Hi RP,
>
> Should we make HIGH_RLIMIT_NOFILE configurable from local.conf?
>
> Then we could modify it according to the requirement, such as set it to 4k
> at image test
>
> //Hongxu
>
>
> Alex
>
> On Mon, 19 Aug 2019 at 15:34, Hongxu Jia <hongxu.jia@windriver.com> wrote:
>
>> Since do_testimage for core-image-sato-sdk has memory limitation (256Mib)
>> which caused rpc.statd failed with out of memory.
>> [  531.306146] Out of memory: Kill process 193 (rpc.statd) score 200 or
>> sacrifice child
>>
>> The rpc.statd allocates memory according to RLIMIT_NOFILE,
>> so decrease it to 4k to keep sync with sysvinit
>>
>> After applying the patch, the memory cost is the same with sysvinit
>> rpcuser    340  0.0  1.0   3212  2588 ?        Ss   13:20   0:00
>> /usr/sbin/rpc.statd -F
>> root       473  0.0  0.2   3464   496 ?        Ss   13:23   0:00
>> /usr/sbin/rpc.mountd
>>
>> Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
>> ---
>>  ...0001-decreasing-the-default-RLIMIT_NOFILE.patch | 35
>> ++++++++++++++++++++++
>>  meta/recipes-core/systemd/systemd_242.bb           |  4 +++
>>  2 files changed, 39 insertions(+)
>>  create mode 100644
>> meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
>>
>> diff --git
>> a/meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
>> b/meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
>> new file mode 100644
>> index 0000000..fb8e2c9
>> --- /dev/null
>> +++
>> b/meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
>> @@ -0,0 +1,35 @@
>> +From 55c7196163e481c508fa708b9b8f5e7bf2d2f007 Mon Sep 17 00:00:00 2001
>> +From: Hongxu Jia <hongxu.jia@windriver.com>
>> +Date: Mon, 19 Aug 2019 07:16:47 -0400
>> +Subject: [PATCH] decreasing the default RLIMIT_NOFILE
>> +
>> +Since do_testimage for core-image-sato-sdk has memory limits (256Mib)
>> +which caused rpc.statd failed with out of memory.
>> +[  531.306146] Out of memory: Kill process 193 (rpc.statd) score 200 or
>> sacrifice child
>> +
>> +The rpc.statd allocates memory according to RLIMIT_NOFILE,
>> +so decrease it to 4k which keep sync with sysvinit
>> +
>> +Upstream-Status: Inappropriate [oe specific]
>> +
>> +Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
>> +---
>> + meson.build | 2 +-
>> + 1 file changed, 1 insertion(+), 1 deletion(-)
>> +
>> +diff --git a/meson.build b/meson.build
>> +index 18a7cc5..e30894b 100644
>> +--- a/meson.build
>> ++++ b/meson.build
>> +@@ -79,7 +79,7 @@ conf.set10('HAVE_SYSV_COMPAT', sysvinit_path != '' and
>> sysvrcnd_path != '',
>> +
>> + conf.set10('BUMP_PROC_SYS_FS_FILE_MAX',
>> get_option('bump-proc-sys-fs-file-max'))
>> + conf.set10('BUMP_PROC_SYS_FS_NR_OPEN',
>> get_option('bump-proc-sys-fs-nr-open'))
>> +-conf.set('HIGH_RLIMIT_NOFILE',          512*1024)
>> ++conf.set('HIGH_RLIMIT_NOFILE',          4*1024)
>> +
>> + # join_paths ignores the preceding arguments if an absolute component is
>> + # encountered, so this should canonicalize various paths when they are
>> +--
>> +2.8.1
>> +
>> diff --git a/meta/recipes-core/systemd/systemd_242.bb
>> b/meta/recipes-core/systemd/systemd_242.bb
>> index 1953fef..ab15ad2 100644
>> --- a/meta/recipes-core/systemd/systemd_242.bb
>> +++ b/meta/recipes-core/systemd/systemd_242.bb
>> @@ -58,6 +58,10 @@ SRC_URI_MUSL = "
>> file://0001-Use-getenv-when-secure-versions-are-not-available.pa
>>                 file://0001-do-not-disable-buffer-in-writing-files.patch
>> \
>>                 "
>>
>> +SRC_URI_append_qemuall = " \
>> +               file://0001-decreasing-the-default-RLIMIT_NOFILE.patch \
>> +"
>> +
>>  PAM_PLUGINS = " \
>>      pam-plugin-unix \
>>      pam-plugin-loginuid \
>> --
>> 2.8.1
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>
>

[-- Attachment #2: Type: text/html, Size: 8663 bytes --]

Re: [PATCH] systemd: decreasing default RLIMIT_NOFILE on qemu bsp

[richard.purdie]

On Mon, 2019-08-19 at 16:01 +0200, Alexander Kanavin wrote:
> Should the limit be simply raised? The 256M setup is crumbling on
> several fronts (runtime tests, modernisation of X, various non-x86
> qemu targets). Adding per-image/target exceptions, custom non-
> upstreamable patches, or sticking to deprecated configurations isn't
> the right thing to do, I think.

What kind of devices/uses are we meant to be targeting?

I believe OE is suited to optimised used cases where constraints on
size and performance are quite likely and supported.

This is *exactly* the kind of thing we should be exploring and
supporting. systemd is not designed for some of the systems we target.
Changing some of its configuration shouldn't be a surprise.

Having NFS taking up half the available memory doesn't make sense,
particularly when the sysvinit limits have worked for us for years. I
therefore appreciate Hongxu figuring out what the difference was and I
believe we should change this to something more suited for our target
audience, unless someone can explain why this is a bad idea.

Similarly, forcing everyone to full GL stacks under qemu simply is not
acceptable. For example I might have a single container type image
which I want to load/test under qemu. Forcing such usage to require
512MB memory for what could be a headless system also isn't right and
will just frustrate users. Users need to be able to access headless or
2D configurations of it.

I'm sorry I haven't been as active with general patch review recently
as I'd like. I did say that trying to change runqueue would distract me
from the usual day to day running of the project. We need to sort this
problem out but not the way you keep trying to.

Where images have specific memory needs, we should increase the
headroom for those images. Images with SDK tools, or stap make sense to
have more memory.

I'd even possibly accept a case for higher memory defaults for graphics
images when GL is enabled. Pushing the default qemu memory size to
512MB everywhere is wrong though and sends out the wrong message for
the project.

Cheers,

Richard

Re: [PATCH] systemd: decreasing default RLIMIT_NOFILE on qemu bsp

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]

On Mon, 19 Aug 2019 at 16:55, <richard.purdie@linuxfoundation.org> wrote:

> I'd even possibly accept a case for higher memory defaults for graphics
> images when GL is enabled. Pushing the default qemu memory size to
> 512MB everywhere is wrong though and sends out the wrong message for
> the project.
>

Thanks for the response (I do realize runqueue work is making you less
available).

I have basically one objection: trying to understand what went wrong in a
OOM situation, where the symptoms and error messages are unhelpful and
tools to diagnose the issue are missing from the target image, is just as
frustrating. Having a tighter limit makes this more likely to occur when
users experiment with images and add or change things in them (e.g. via
local.conf). You, me or Hongxu would dig deeper and get to the bottom of
it, but someone just starting out with the project could simply give up and
move to alternatives.

Other than that, I am fine with raising the memory in a more targeted way
(e.g. core-image-sato, subject to 'opengl' in DISTRO_FEATURES and elsewhere
where X would otherwise fail to start), and will rework the patches
accordingly.

Cheers,
Alex

[-- Attachment #2: Type: text/html, Size: 1660 bytes --]

[PATCH V2] systemd: add menson option to decrease RLIMIT_NOFILE on qemu bsp

[Hongxu Jia]

Since do_testimage for core-image-sato-sdk has memory limitation (256Mib)
which caused rpc.statd failed with out of memory.
[  531.306146] Out of memory: Kill process 193 (rpc.statd) score 200 or sacrifice child

The rpc.statd allocates memory according to RLIMIT_NOFILE,
so decrease RLIMIT_NOFILE to 4k to keep sync with sysvinit

After applying the patch, the memory cost is the same with sysvinit
rpcuser    340  0.0  1.0   3212  2588 ?        Ss   13:20   0:00 /usr/sbin/rpc.statd -F
root       473  0.0  0.2   3464   496 ?        Ss   13:23   0:00 /usr/sbin/rpc.mountd

For other bsp, still keep RLIMIT_NOFILE to 512k by default

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
---
 ...001-meson-add-option-to-set-RLIMIT_NOFILE.patch | 50 ++++++++++++++++++++++
 meta/recipes-core/systemd/systemd_242.bb           |  5 +++
 2 files changed, 55 insertions(+)
 create mode 100644 meta/recipes-core/systemd/systemd/0001-meson-add-option-to-set-RLIMIT_NOFILE.patch

diff --git a/meta/recipes-core/systemd/systemd/0001-meson-add-option-to-set-RLIMIT_NOFILE.patch b/meta/recipes-core/systemd/systemd/0001-meson-add-option-to-set-RLIMIT_NOFILE.patch
new file mode 100644
index 0000000..e822238
--- /dev/null
+++ b/meta/recipes-core/systemd/systemd/0001-meson-add-option-to-set-RLIMIT_NOFILE.patch
@@ -0,0 +1,50 @@
+From d42d1512402de0d2249e2d68040c5c3887e7ea99 Mon Sep 17 00:00:00 2001
+From: Hongxu Jia <hongxu.jia@windriver.com>
+Date: Mon, 19 Aug 2019 12:06:59 -0400
+Subject: [PATCH] meson: add option to set RLIMIT_NOFILE
+
+Add option to set RLIMIT_NOFILE and keep 512*1024 by default
+
+It is helpful for embedded device which has memory limitation
+to decrease RLIMIT_NOFILE
+
+Upstream-Status: Submitted [https://github.com/systemd/systemd/pull/13359]
+
+Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
+---
+ meson.build       | 2 +-
+ meson_options.txt | 5 +++++
+ 2 files changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/meson.build b/meson.build
+index 18a7cc5..26d9cf0 100644
+--- a/meson.build
++++ b/meson.build
+@@ -79,7 +79,7 @@ conf.set10('HAVE_SYSV_COMPAT', sysvinit_path != '' and sysvrcnd_path != '',
+ 
+ conf.set10('BUMP_PROC_SYS_FS_FILE_MAX', get_option('bump-proc-sys-fs-file-max'))
+ conf.set10('BUMP_PROC_SYS_FS_NR_OPEN',  get_option('bump-proc-sys-fs-nr-open'))
+-conf.set('HIGH_RLIMIT_NOFILE',          512*1024)
++conf.set('HIGH_RLIMIT_NOFILE',          get_option('high-rlimit-nofile'))
+ 
+ # join_paths ignores the preceding arguments if an absolute component is
+ # encountered, so this should canonicalize various paths when they are
+diff --git a/meson_options.txt b/meson_options.txt
+index d4ec37d..5d4ee18 100644
+--- a/meson_options.txt
++++ b/meson_options.txt
+@@ -56,6 +56,11 @@ option('bump-proc-sys-fs-file-max', type : 'boolean',
+        description : 'bump /proc/sys/fs/file-max to ULONG_MAX')
+ option('bump-proc-sys-fs-nr-open', type : 'boolean',
+        description : 'bump /proc/sys/fs/nr_open to INT_MAX')
++
++# Default is 512*1024
++option('high-rlimit-nofile', type : 'integer', value : 524288,
++       description : 'set RLIMIT_NOFILE')
++
+ option('valgrind', type : 'boolean', value : false,
+        description : 'do extra operations to avoid valgrind warnings')
+ option('log-trace', type : 'boolean', value : false,
+-- 
+2.8.1
+
diff --git a/meta/recipes-core/systemd/systemd_242.bb b/meta/recipes-core/systemd/systemd_242.bb
index 1953fef..96a53dc 100644
--- a/meta/recipes-core/systemd/systemd_242.bb
+++ b/meta/recipes-core/systemd/systemd_242.bb
@@ -28,6 +28,7 @@ SRC_URI += "file://touchscreen.rules \
            file://0001-core-set-fs.file-max-sysctl-to-LONG_MAX-rather-than-.patch \
            file://0001-networkd-fix-link-up.patch \
            file://0002-network-do-not-send-ipv6.patch \
+           file://0001-meson-add-option-to-set-RLIMIT_NOFILE.patch \
            "
 
 # patches needed by musl
@@ -211,6 +212,10 @@ EXTRA_OEMESON += "-Dkexec-path=${sbindir}/kexec \
                   -Dsulogin-path=${base_sbindir}/sulogin \
                   -Dumount-path=${base_bindir}/umount"
 
+EXTRA_OEMESON += "-Dhigh-rlimit-nofile=${RLIMIT_NOFILE}"
+RLIMIT_NOFILE ??= "524288"
+RLIMIT_NOFILE_qemuall ?= "4096"
+
 do_install() {
 	meson_do_install
 	install -d ${D}/${base_sbindir}
-- 
2.8.1

Re: [PATCH V2] systemd: add menson option to decrease RLIMIT_NOFILE on qemu bsp

[Andre McCurdy]

On Mon, Aug 19, 2019 at 9:38 AM Hongxu Jia <hongxu.jia@windriver.com> wrote:
>
> Since do_testimage for core-image-sato-sdk has memory limitation (256Mib)
> which caused rpc.statd failed with out of memory.
> [  531.306146] Out of memory: Kill process 193 (rpc.statd) score 200 or sacrifice child
>
> The rpc.statd allocates memory according to RLIMIT_NOFILE,
> so decrease RLIMIT_NOFILE to 4k to keep sync with sysvinit
>
> After applying the patch, the memory cost is the same with sysvinit
> rpcuser    340  0.0  1.0   3212  2588 ?        Ss   13:20   0:00 /usr/sbin/rpc.statd -F
> root       473  0.0  0.2   3464   496 ?        Ss   13:23   0:00 /usr/sbin/rpc.mountd
>
> For other bsp, still keep RLIMIT_NOFILE to 512k by default
>
> Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
> ---
>  ...001-meson-add-option-to-set-RLIMIT_NOFILE.patch | 50 ++++++++++++++++++++++
>  meta/recipes-core/systemd/systemd_242.bb           |  5 +++
>  2 files changed, 55 insertions(+)
>  create mode 100644 meta/recipes-core/systemd/systemd/0001-meson-add-option-to-set-RLIMIT_NOFILE.patch
>
> diff --git a/meta/recipes-core/systemd/systemd/0001-meson-add-option-to-set-RLIMIT_NOFILE.patch b/meta/recipes-core/systemd/systemd/0001-meson-add-option-to-set-RLIMIT_NOFILE.patch
> new file mode 100644
> index 0000000..e822238
> --- /dev/null
> +++ b/meta/recipes-core/systemd/systemd/0001-meson-add-option-to-set-RLIMIT_NOFILE.patch
> @@ -0,0 +1,50 @@
> +From d42d1512402de0d2249e2d68040c5c3887e7ea99 Mon Sep 17 00:00:00 2001
> +From: Hongxu Jia <hongxu.jia@windriver.com>
> +Date: Mon, 19 Aug 2019 12:06:59 -0400
> +Subject: [PATCH] meson: add option to set RLIMIT_NOFILE
> +
> +Add option to set RLIMIT_NOFILE and keep 512*1024 by default
> +
> +It is helpful for embedded device which has memory limitation
> +to decrease RLIMIT_NOFILE
> +
> +Upstream-Status: Submitted [https://github.com/systemd/systemd/pull/13359]
> +
> +Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
> +---
> + meson.build       | 2 +-
> + meson_options.txt | 5 +++++
> + 2 files changed, 6 insertions(+), 1 deletion(-)
> +
> +diff --git a/meson.build b/meson.build
> +index 18a7cc5..26d9cf0 100644
> +--- a/meson.build
> ++++ b/meson.build
> +@@ -79,7 +79,7 @@ conf.set10('HAVE_SYSV_COMPAT', sysvinit_path != '' and sysvrcnd_path != '',
> +
> + conf.set10('BUMP_PROC_SYS_FS_FILE_MAX', get_option('bump-proc-sys-fs-file-max'))
> + conf.set10('BUMP_PROC_SYS_FS_NR_OPEN',  get_option('bump-proc-sys-fs-nr-open'))
> +-conf.set('HIGH_RLIMIT_NOFILE',          512*1024)
> ++conf.set('HIGH_RLIMIT_NOFILE',          get_option('high-rlimit-nofile'))
> +
> + # join_paths ignores the preceding arguments if an absolute component is
> + # encountered, so this should canonicalize various paths when they are
> +diff --git a/meson_options.txt b/meson_options.txt
> +index d4ec37d..5d4ee18 100644
> +--- a/meson_options.txt
> ++++ b/meson_options.txt
> +@@ -56,6 +56,11 @@ option('bump-proc-sys-fs-file-max', type : 'boolean',
> +        description : 'bump /proc/sys/fs/file-max to ULONG_MAX')
> + option('bump-proc-sys-fs-nr-open', type : 'boolean',
> +        description : 'bump /proc/sys/fs/nr_open to INT_MAX')
> ++
> ++# Default is 512*1024
> ++option('high-rlimit-nofile', type : 'integer', value : 524288,
> ++       description : 'set RLIMIT_NOFILE')
> ++
> + option('valgrind', type : 'boolean', value : false,
> +        description : 'do extra operations to avoid valgrind warnings')
> + option('log-trace', type : 'boolean', value : false,
> +--
> +2.8.1
> +
> diff --git a/meta/recipes-core/systemd/systemd_242.bb b/meta/recipes-core/systemd/systemd_242.bb
> index 1953fef..96a53dc 100644
> --- a/meta/recipes-core/systemd/systemd_242.bb
> +++ b/meta/recipes-core/systemd/systemd_242.bb
> @@ -28,6 +28,7 @@ SRC_URI += "file://touchscreen.rules \
>             file://0001-core-set-fs.file-max-sysctl-to-LONG_MAX-rather-than-.patch \
>             file://0001-networkd-fix-link-up.patch \
>             file://0002-network-do-not-send-ipv6.patch \
> +           file://0001-meson-add-option-to-set-RLIMIT_NOFILE.patch \
>             "
>
>  # patches needed by musl
> @@ -211,6 +212,10 @@ EXTRA_OEMESON += "-Dkexec-path=${sbindir}/kexec \
>                    -Dsulogin-path=${base_sbindir}/sulogin \
>                    -Dumount-path=${base_bindir}/umount"
>
> +EXTRA_OEMESON += "-Dhigh-rlimit-nofile=${RLIMIT_NOFILE}"
> +RLIMIT_NOFILE ??= "524288"
> +RLIMIT_NOFILE_qemuall ?= "4096"

This doesn't look right. By making the fix qemu specific you're
effectively changing the QA tests to pass - but leaving the underlying
issue there for all real world use cases.

Better to set the safe value by default and let users with lots of
memory change it if they need to.

> +
>  do_install() {
>         meson_do_install
>         install -d ${D}/${base_sbindir}
> --
> 2.8.1
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

[PATCH V3] nfs-utils: decrease RLIMIT_NOFILE to 4k for systemd

[Hongxu Jia]

On systemd, it set RLIMIT_NOFILE to 512k, since do_testimage
for core-image-sato-sdk has memory limitation (256Mib) which
caused rpc.statd failed with out of memory.
[  531.306146] Out of memory: Kill process 193 (rpc.statd) score 200 or sacrifice child

The rpc.statd and rpc.mountd allocates memory according to
RLIMIT_NOFILE, so decrease it to 4k to keep sync with sysvinit

After applying the patch, the memory cost is the same with sysvinit:

root@qemux86-64:~# systemctl status nfs-statd
* nfs-statd.service - NFS status monitor for NFSv2/3 locking.
   Loaded: loaded (/lib/systemd/system/nfs-statd.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2019-08-20 03:16:18 UTC; 3min 26s ago
 Main PID: 343 (rpc.statd)
    Tasks: 1 (limit: 271)
   Memory: 1.0M

root@qemux86-64:~# systemctl status nfs-mountd
* nfs-mountd.service - NFS Mount Daemon
   Loaded: loaded (/etc/systemd/system/nfs-mountd.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2019-08-20 03:19:01 UTC; 1min 21s ago
 Main PID: 451 (rpc.mountd)
    Tasks: 1 (limit: 271)
   Memory: 736.0K

Suggested-by: Chen Qi <qi.chen@windriver.com>
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
---
 meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-mountd.service | 1 +
 meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-statd.service  | 1 +
 meta/recipes-connectivity/nfs-utils/nfs-utils_2.3.3.bb           | 4 ++++
 3 files changed, 6 insertions(+)

diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-mountd.service b/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-mountd.service
index 3c3a802..c01415d 100644
--- a/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-mountd.service
+++ b/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-mountd.service
@@ -11,6 +11,7 @@ ConditionPathExists=@SYSCONFDIR@/exports
 [Service]
 EnvironmentFile=-@SYSCONFDIR@/nfs-utils.conf
 ExecStart=@SBINDIR@/rpc.mountd -F $MOUNTD_OPTS
+LimitNOFILE=@HIGH_RLIMIT_NOFILE@
 
 [Install]
 WantedBy=multi-user.target
diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-statd.service b/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-statd.service
index 6e196b8..4fa64e1 100644
--- a/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-statd.service
+++ b/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-statd.service
@@ -8,6 +8,7 @@ After=network.target nss-lookup.target rpcbind.service
 [Service]
 EnvironmentFile=-@SYSCONFDIR@/nfs-utils.conf
 ExecStart=@SBINDIR@/rpc.statd -F $STATD_OPTS
+LimitNOFILE=@HIGH_RLIMIT_NOFILE@
 
 [Install]
 WantedBy=multi-user.target
diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_2.3.3.bb b/meta/recipes-connectivity/nfs-utils/nfs-utils_2.3.3.bb
index ac4437b..28f9898 100644
--- a/meta/recipes-connectivity/nfs-utils/nfs-utils_2.3.3.bb
+++ b/meta/recipes-connectivity/nfs-utils/nfs-utils_2.3.3.bb
@@ -119,6 +119,9 @@ do_compile_prepend() {
 	make clean
 }
 
+# Works on systemd only
+HIGH_RLIMIT_NOFILE ??= "4096"
+
 do_install_append () {
 	install -d ${D}${sysconfdir}/init.d
 	install -m 0755 ${WORKDIR}/nfsserver ${D}${sysconfdir}/init.d/nfsserver
@@ -133,6 +136,7 @@ do_install_append () {
 	install -m 0644 ${WORKDIR}/nfs-statd.service ${D}${systemd_unitdir}/system/
 	sed -i -e 's,@SBINDIR@,${sbindir},g' \
 		-e 's,@SYSCONFDIR@,${sysconfdir},g' \
+		-e 's,@HIGH_RLIMIT_NOFILE@,${HIGH_RLIMIT_NOFILE},g' \
 		${D}${systemd_unitdir}/system/*.service
 	if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then
 	    install -m 0644 ${WORKDIR}/proc-fs-nfsd.mount ${D}${systemd_unitdir}/system/
-- 
2.8.1

Re: [PATCH] systemd: decreasing default RLIMIT_NOFILE on qemu bsp

[Mark Hatle]

On 8/19/19 9:55 AM, richard.purdie@linuxfoundation.org wrote:
> On Mon, 2019-08-19 at 16:01 +0200, Alexander Kanavin wrote:
>> Should the limit be simply raised? The 256M setup is crumbling on
>> several fronts (runtime tests, modernisation of X, various non-x86
>> qemu targets). Adding per-image/target exceptions, custom non-
>> upstreamable patches, or sticking to deprecated configurations isn't
>> the right thing to do, I think.
> 
> What kind of devices/uses are we meant to be targeting?
> 
> I believe OE is suited to optimised used cases where constraints on
> size and performance are quite likely and supported.
> 
> This is *exactly* the kind of thing we should be exploring and
> supporting. systemd is not designed for some of the systems we target.
> Changing some of its configuration shouldn't be a surprise.
> 
> Having NFS taking up half the available memory doesn't make sense,
> particularly when the sysvinit limits have worked for us for years. I
> therefore appreciate Hongxu figuring out what the difference was and I
> believe we should change this to something more suited for our target
> audience, unless someone can explain why this is a bad idea.
> 
> Similarly, forcing everyone to full GL stacks under qemu simply is not
> acceptable. For example I might have a single container type image
> which I want to load/test under qemu. Forcing such usage to require
> 512MB memory for what could be a headless system also isn't right and
> will just frustrate users. Users need to be able to access headless or
> 2D configurations of it.

Looking at what my customers are doing, I completely agree.  I look at the
design criteria for my customer's devices and I'm seeing 256MB as -very- common.
 More happens, but it's rare still.  (But I have some customers with GB of ram,
but that is usually to support their application, but the base system!)

(Note, I do have customers -with- graphics requirements [X11] that are in the
128/256 MB ram ranges.  In most cases OpenGL is something they would like, but I
don't believe it's a hard requirement for them.)

I do still have many customers with 128 MB of ram requirements.  So it's
important for us to set a reasonable baseline (256MB).  So going under this
requires 'work', but I think that is acceptable.

--Mark

> I'm sorry I haven't been as active with general patch review recently
> as I'd like. I did say that trying to change runqueue would distract me
> from the usual day to day running of the project. We need to sort this
> problem out but not the way you keep trying to.
> 
> Where images have specific memory needs, we should increase the
> headroom for those images. Images with SDK tools, or stap make sense to
> have more memory.
> 
> I'd even possibly accept a case for higher memory defaults for graphics
> images when GL is enabled. Pushing the default qemu memory size to
> 512MB everywhere is wrong though and sends out the wrong message for
> the project.
> 
> Cheers,
> 
> Richard
> 
> 

Re: [PATCH] systemd: decreasing default RLIMIT_NOFILE on qemu bsp

[Adrian Bunk]

On Tue, Aug 20, 2019 at 08:46:53AM -0500, Mark Hatle wrote:
> On 8/19/19 9:55 AM, richard.purdie@linuxfoundation.org wrote:
> > On Mon, 2019-08-19 at 16:01 +0200, Alexander Kanavin wrote:
> >> Should the limit be simply raised? The 256M setup is crumbling on
> >> several fronts (runtime tests, modernisation of X, various non-x86
> >> qemu targets). Adding per-image/target exceptions, custom non-
> >> upstreamable patches, or sticking to deprecated configurations isn't
> >> the right thing to do, I think.
> > 
> > What kind of devices/uses are we meant to be targeting?
> > 
> > I believe OE is suited to optimised used cases where constraints on
> > size and performance are quite likely and supported.
> > 
> > This is *exactly* the kind of thing we should be exploring and
> > supporting. systemd is not designed for some of the systems we target.
> > Changing some of its configuration shouldn't be a surprise.
> > 
> > Having NFS taking up half the available memory doesn't make sense,
> > particularly when the sysvinit limits have worked for us for years. I
> > therefore appreciate Hongxu figuring out what the difference was and I
> > believe we should change this to something more suited for our target
> > audience, unless someone can explain why this is a bad idea.
> > 
> > Similarly, forcing everyone to full GL stacks under qemu simply is not
> > acceptable. For example I might have a single container type image
> > which I want to load/test under qemu. Forcing such usage to require
> > 512MB memory for what could be a headless system also isn't right and
> > will just frustrate users. Users need to be able to access headless or
> > 2D configurations of it.
> 
> Looking at what my customers are doing, I completely agree.  I look at the
> design criteria for my customer's devices and I'm seeing 256MB as -very- common.
>  More happens, but it's rare still.  (But I have some customers with GB of ram,
> but that is usually to support their application, but the base system!)
> 
> (Note, I do have customers -with- graphics requirements [X11] that are in the
> 128/256 MB ram ranges.  In most cases OpenGL is something they would like, but I
> don't believe it's a hard requirement for them.)
> 
> I do still have many customers with 128 MB of ram requirements.  So it's
> important for us to set a reasonable baseline (256MB).  So going under this
> requires 'work', but I think that is acceptable.

There is also a certain disconnect between these numbers and the 
constant pain for everyone of keeping everything building with
musl for small size gain.

128 MB RAM and 16 MB flash would be a configuration where I would not 
worry about size enough to consider glibc a problem.

Is there real-world demand for running X11 with musl?

Is there a CI setup ensuring that disk and RAM usage of relevant
musl setups don't regress - which might be more than the gains
of musl compared to glibc?

> --Mark

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH] systemd: decreasing default RLIMIT_NOFILE on qemu bsp

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 1664 bytes --]

On Tue, 20 Aug 2019 at 15:46, Mark Hatle <mark.hatle@windriver.com> wrote:

> Looking at what my customers are doing, I completely agree.  I look at the
> design criteria for my customer's devices and I'm seeing 256MB as -very-
> common.
>  More happens, but it's rare still.  (But I have some customers with GB of
> ram,
> but that is usually to support their application, but the base system!)
>
> (Note, I do have customers -with- graphics requirements [X11] that are in
> the
> 128/256 MB ram ranges.  In most cases OpenGL is something they would like,
> but I
> don't believe it's a hard requirement for them.)
>
> I do still have many customers with 128 MB of ram requirements.  So it's
> important for us to set a reasonable baseline (256MB).  So going under this
> requires 'work', but I think that is acceptable.
>

For contrast, in the kind of system I am helping to develop everything is
measured in gigabytes. RAM should be in the ballpark of 10Gb. Disk storage
maybe 10x that. OpenGL is at the foundation of display output and isn't
optional in any way. There's basically every connectivity option enabled,
multiple cameras, touchscreens and whatnot. The whole thing will eventually
look not that far from iOS in terms of UI and capabilities and
containerized 3rd party apps (except it *also* needs to support multiple
screens and multiple users). And yes, it's all pulled together through
bitbake and a zoo of layers, images and target configurations. Yocto is
able to target cases like this, which is amazing - hopefully this clears up
a bit where I am coming from in this, even if it's a 'minority' position.

Alex

[-- Attachment #2: Type: text/html, Size: 2072 bytes --]

Re: [PATCH] systemd: decreasing default RLIMIT_NOFILE on qemu bsp

[Mark Hatle]

On 8/20/19 11:38 AM, Adrian Bunk wrote:
> On Tue, Aug 20, 2019 at 08:46:53AM -0500, Mark Hatle wrote:
>> On 8/19/19 9:55 AM, richard.purdie@linuxfoundation.org wrote:
>>> On Mon, 2019-08-19 at 16:01 +0200, Alexander Kanavin wrote:
>>>> Should the limit be simply raised? The 256M setup is crumbling on
>>>> several fronts (runtime tests, modernisation of X, various non-x86
>>>> qemu targets). Adding per-image/target exceptions, custom non-
>>>> upstreamable patches, or sticking to deprecated configurations isn't
>>>> the right thing to do, I think.
>>>
>>> What kind of devices/uses are we meant to be targeting?
>>>
>>> I believe OE is suited to optimised used cases where constraints on
>>> size and performance are quite likely and supported.
>>>
>>> This is *exactly* the kind of thing we should be exploring and
>>> supporting. systemd is not designed for some of the systems we target.
>>> Changing some of its configuration shouldn't be a surprise.
>>>
>>> Having NFS taking up half the available memory doesn't make sense,
>>> particularly when the sysvinit limits have worked for us for years. I
>>> therefore appreciate Hongxu figuring out what the difference was and I
>>> believe we should change this to something more suited for our target
>>> audience, unless someone can explain why this is a bad idea.
>>>
>>> Similarly, forcing everyone to full GL stacks under qemu simply is not
>>> acceptable. For example I might have a single container type image
>>> which I want to load/test under qemu. Forcing such usage to require
>>> 512MB memory for what could be a headless system also isn't right and
>>> will just frustrate users. Users need to be able to access headless or
>>> 2D configurations of it.
>>
>> Looking at what my customers are doing, I completely agree.  I look at the
>> design criteria for my customer's devices and I'm seeing 256MB as -very- common.
>>  More happens, but it's rare still.  (But I have some customers with GB of ram,
>> but that is usually to support their application, but the base system!)
>>
>> (Note, I do have customers -with- graphics requirements [X11] that are in the
>> 128/256 MB ram ranges.  In most cases OpenGL is something they would like, but I
>> don't believe it's a hard requirement for them.)
>>
>> I do still have many customers with 128 MB of ram requirements.  So it's
>> important for us to set a reasonable baseline (256MB).  So going under this
>> requires 'work', but I think that is acceptable.
> 
> There is also a certain disconnect between these numbers and the 
> constant pain for everyone of keeping everything building with
> musl for small size gain.
> 
> 128 MB RAM and 16 MB flash would be a configuration where I would not 
> worry about size enough to consider glibc a problem.
> 
> Is there real-world demand for running X11 with musl?

Size is only one reason for musl, the other is to have a non-GPL libc in the device.

--Mark

> Is there a CI setup ensuring that disk and RAM usage of relevant
> musl setups don't regress - which might be more than the gains
> of musl compared to glibc?
> 
>> --Mark
> 
> cu
> Adrian
> 

Re: [PATCH] systemd: decreasing default RLIMIT_NOFILE on qemu bsp

[Richard Purdie]

On Tue, 2019-08-20 at 22:20 +0200, Alexander Kanavin wrote:
> On Tue, 20 Aug 2019 at 15:46, Mark Hatle <mark.hatle@windriver.com>
> wrote:
> > Looking at what my customers are doing, I completely agree.  I look
> > at the
> > design criteria for my customer's devices and I'm seeing 256MB as
> > -very- common.
> >  More happens, but it's rare still.  (But I have some customers
> > with GB of ram,
> > but that is usually to support their application, but the base
> > system!)
> > 
> > (Note, I do have customers -with- graphics requirements [X11] that
> > are in the
> > 128/256 MB ram ranges.  In most cases OpenGL is something they
> > would like, but I
> > don't believe it's a hard requirement for them.)
> > 
> > I do still have many customers with 128 MB of ram requirements.  So
> > it's
> > important for us to set a reasonable baseline (256MB).  So going
> > under this
> > requires 'work', but I think that is acceptable.
> 
> For contrast, in the kind of system I am helping to develop
> everything is measured in gigabytes. RAM should be in the ballpark of
> 10Gb. Disk storage maybe 10x that. OpenGL is at the foundation of
> display output and isn't optional in any way. There's basically every
> connectivity option enabled, multiple cameras, touchscreens and
> whatnot. The whole thing will eventually look not that far from iOS
> in terms of UI and capabilities and containerized 3rd party apps
> (except it *also* needs to support multiple screens and multiple
> users). And yes, it's all pulled together through bitbake and a zoo
> of layers, images and target configurations. Yocto is able to target
> cases like this, which is amazing - hopefully this clears up a bit
> where I am coming from in this, even if it's a 'minority' position.

I don't think its a minority and there are people who have both kinds
of system, sometimes in the same build.

We just need to be mindful we have a spectrum of target users and low
RAM is one part of that matrix. I want the project to support the
larger use cases too.

Cheers,

Richard

Re: [PATCH V3] nfs-utils: decrease RLIMIT_NOFILE to 4k for systemd

[Kang Kai]

On 2019/8/20 下午1:45, Hongxu Jia wrote:
> On systemd, it set RLIMIT_NOFILE to 512k, since do_testimage
> for core-image-sato-sdk has memory limitation (256Mib) which
> caused rpc.statd failed with out of memory.
> [  531.306146] Out of memory: Kill process 193 (rpc.statd) score 200 or sacrifice child
>
> The rpc.statd and rpc.mountd allocates memory according to
> RLIMIT_NOFILE, so decrease it to 4k to keep sync with sysvinit

Hi Richard,

This patch could fix the test_image failure with systemd. Would like to 
try systemd as default init manager on yocto build again
to check whether any more blocking issues?

Thanks,
Kai


>
> After applying the patch, the memory cost is the same with sysvinit:
>
> root@qemux86-64:~# systemctl status nfs-statd
> * nfs-statd.service - NFS status monitor for NFSv2/3 locking.
>     Loaded: loaded (/lib/systemd/system/nfs-statd.service; enabled; vendor preset: enabled)
>     Active: active (running) since Tue 2019-08-20 03:16:18 UTC; 3min 26s ago
>   Main PID: 343 (rpc.statd)
>      Tasks: 1 (limit: 271)
>     Memory: 1.0M
>
> root@qemux86-64:~# systemctl status nfs-mountd
> * nfs-mountd.service - NFS Mount Daemon
>     Loaded: loaded (/etc/systemd/system/nfs-mountd.service; enabled; vendor preset: enabled)
>     Active: active (running) since Tue 2019-08-20 03:19:01 UTC; 1min 21s ago
>   Main PID: 451 (rpc.mountd)
>      Tasks: 1 (limit: 271)
>     Memory: 736.0K
>
> Suggested-by: Chen Qi <qi.chen@windriver.com>
> Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
> ---
>   meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-mountd.service | 1 +
>   meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-statd.service  | 1 +
>   meta/recipes-connectivity/nfs-utils/nfs-utils_2.3.3.bb           | 4 ++++
>   3 files changed, 6 insertions(+)
>
> diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-mountd.service b/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-mountd.service
> index 3c3a802..c01415d 100644
> --- a/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-mountd.service
> +++ b/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-mountd.service
> @@ -11,6 +11,7 @@ ConditionPathExists=@SYSCONFDIR@/exports
>   [Service]
>   EnvironmentFile=-@SYSCONFDIR@/nfs-utils.conf
>   ExecStart=@SBINDIR@/rpc.mountd -F $MOUNTD_OPTS
> +LimitNOFILE=@HIGH_RLIMIT_NOFILE@
>   
>   [Install]
>   WantedBy=multi-user.target
> diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-statd.service b/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-statd.service
> index 6e196b8..4fa64e1 100644
> --- a/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-statd.service
> +++ b/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-statd.service
> @@ -8,6 +8,7 @@ After=network.target nss-lookup.target rpcbind.service
>   [Service]
>   EnvironmentFile=-@SYSCONFDIR@/nfs-utils.conf
>   ExecStart=@SBINDIR@/rpc.statd -F $STATD_OPTS
> +LimitNOFILE=@HIGH_RLIMIT_NOFILE@
>   
>   [Install]
>   WantedBy=multi-user.target
> diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_2.3.3.bb b/meta/recipes-connectivity/nfs-utils/nfs-utils_2.3.3.bb
> index ac4437b..28f9898 100644
> --- a/meta/recipes-connectivity/nfs-utils/nfs-utils_2.3.3.bb
> +++ b/meta/recipes-connectivity/nfs-utils/nfs-utils_2.3.3.bb
> @@ -119,6 +119,9 @@ do_compile_prepend() {
>   	make clean
>   }
>   
> +# Works on systemd only
> +HIGH_RLIMIT_NOFILE ??= "4096"
> +
>   do_install_append () {
>   	install -d ${D}${sysconfdir}/init.d
>   	install -m 0755 ${WORKDIR}/nfsserver ${D}${sysconfdir}/init.d/nfsserver
> @@ -133,6 +136,7 @@ do_install_append () {
>   	install -m 0644 ${WORKDIR}/nfs-statd.service ${D}${systemd_unitdir}/system/
>   	sed -i -e 's,@SBINDIR@,${sbindir},g' \
>   		-e 's,@SYSCONFDIR@,${sysconfdir},g' \
> +		-e 's,@HIGH_RLIMIT_NOFILE@,${HIGH_RLIMIT_NOFILE},g' \
>   		${D}${systemd_unitdir}/system/*.service
>   	if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then
>   	    install -m 0644 ${WORKDIR}/proc-fs-nfsd.mount ${D}${systemd_unitdir}/system/


-- 
Kai Kang

Re: [PATCH V3] nfs-utils: decrease RLIMIT_NOFILE to 4k for systemd

[richard.purdie]

On Tue, 2019-08-27 at 17:43 +0800, Kang Kai wrote:
> Hi Richard,
> 
> This patch could fix the test_image failure with systemd. Would like
> to 
> try systemd as default init manager on yocto build again
> to check whether any more blocking issues?


There is at least one issue:

https://autobuilder.yoctoproject.org/typhoon/#/builders/67/builds/967

Please monitor this build which should show up any other issues: 

https://autobuilder.yoctoproject.org/typhoon/#/builders/85/builds/645

(master-next was looking green other than this change).

Cheers,

Richard

Re: [PATCH V3] nfs-utils: decrease RLIMIT_NOFILE to 4k for systemd

[Kang Kai]

On 2019/8/28 上午7:29, richard.purdie@linuxfoundation.org wrote:
> On Tue, 2019-08-27 at 17:43 +0800, Kang Kai wrote:
>> Hi Richard,
>>
>> This patch could fix the test_image failure with systemd. Would like
>> to
>> try systemd as default init manager on yocto build again
>> to check whether any more blocking issues?
>
> There is at least one issue:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/67/builds/967
>
> Please monitor this build which should show up any other issues:

Got it. Thanks.


>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/85/builds/645
>
> (master-next was looking green other than this change).

It fails with libedit-native do fetch errors. I'll check it but it seems 
not systemd related at first sight.

Regards,
Kai


>
> Cheers,
>
> Richard
>
>

-- 
Kai Kang

Re: [PATCH V3] nfs-utils: decrease RLIMIT_NOFILE to 4k for systemd

[richard.purdie]

On Wed, 2019-08-28 at 09:29 +0800, Kang Kai wrote:
> On 2019/8/28 上午7:29, richard.purdie@linuxfoundation.org wrote:
> > On Tue, 2019-08-27 at 17:43 +0800, Kang Kai wrote:
> > > Hi Richard,
> > > 
> > > This patch could fix the test_image failure with systemd. Would
> > > like
> > > to
> > > try systemd as default init manager on yocto build again
> > > to check whether any more blocking issues?
> > 
> > There is at least one issue:
> > 
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/67/builds/967
> > 
> > Please monitor this build which should show up any other issues:
> 
> Got it. Thanks.
> 
> 
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/85/builds/645
> > 
> > (master-next was looking green other than this change).
> 
> It fails with libedit-native do fetch errors. I'll check it but it
> seems not systemd related at first sight.

Agreed, that is a different issue. For the systemd vs sysvinit we have:

qemux86-lsb parselogs failure:
https://autobuilder.yoctoproject.org/typhoon/#/builders/67/builds/967

qemuarm-lsb parselogs failure:
https://autobuilder.yoctoproject.org/typhoon/#/builders/38/builds/970

qemumips runtime systemd test failure:
https://autobuilder.yoctoproject.org/typhoon/#/builders/60/builds/962

qemumips64 runtime systemd test failure:
https://autobuilder.yoctoproject.org/typhoon/#/builders/74/builds/967

oe-selftest failures:
https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/658
2019-08-28 00:55:15,114 - oe-selftest - INFO - RESULTS -
runqemu.RunqemuTests.test_boot_machine_slirp_qcow2: ERROR (1025.19s)
2019-08-28 00:55:15,114 - oe-selftest - INFO - RESULTS -
runqemu.RunqemuTests.test_boot_recipe_image_vdi: ERROR (1010.73s)
2019-08-28 00:55:15,114 - oe-selftest - INFO - RESULTS -
runqemu.RunqemuTests.test_boot_recipe_image_vmdk: ERROR (1028.30s)
2019-08-28 00:55:15,114 - oe-selftest - INFO - RESULTS -
wic.Wic.test_iso_image: FAILED (63.97s)

and it looks like those runqemu failures happen on
qemux86-64:
https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/969
qemumips:
https://autobuilder.yoctoproject.org/typhoon/#/builders/60/builds/962
qemux86:
https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/961
qemuppc:
https://autobuilder.yoctoproject.org/typhoon/#/builders/63/builds/961
qemumips64:
https://autobuilder.yoctoproject.org/typhoon/#/builders/74/builds/967
qemuarm:
https://autobuilder.yoctoproject.org/typhoon/#/builders/53/builds/969

so it looks like 3-4 different issues.

Cheers,

Richard