[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.purdie at 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