[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.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?

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
>