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

richard.purdie at linuxfoundation.org richard.purdie at linuxfoundation.org
Mon Aug 19 14:55:27 UTC 2019


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




More information about the Openembedded-core mailing list