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

[Mark Hatle]

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.

--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
> 
>