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
