On Tue, Aug 20, 2019 at 08:46:53AM -0500, Mark Hatle wrote:
> 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.
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
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
