Re: [OE-core] [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 
> 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



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [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.pur...@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
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Alexander Kanavin]

On Tue, 20 Aug 2019 at 15:46, Mark Hatle  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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [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.pur...@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

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Mark Hatle]

On 8/19/19 9:55 AM, richard.pur...@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
> 
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Alexander Kanavin]

On Mon, 19 Aug 2019 at 16:55,  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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [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


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Alexander Kanavin]

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  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  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
>> rpcuser340  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 
>> ---
>>  ...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 000..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 
>> +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 
>> +---
>> + 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
>>
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

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

[Hongxu Jia]

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 > 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 mailto:hongxu@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 000..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 mailto:hongxu@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 mailto:hongxu@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



-- 

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

[Alexander Kanavin]

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  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
> rpcuser340  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 
> ---
>  ...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 000..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 
> +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 
> +---
> + 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
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [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
rpcuser340  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 
---
 ...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 000..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 
+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 
+---
+ 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