On Wed, 14 Aug 2019 at 18:42, Richard Purdie < richard.pur...@linuxfoundation.org> wrote:
> I'm not sure I agree with this. > > We are meant to work on embedded systems and 256MB should be enough to > let us bring up X under qemu. > > I'm fine with some sdk/ptest images having more memory, that makes > sense but 256MB not allowing X under qemu seems rather poor. > > Are we really saying the minimal image size we can emulate is 256MB > ram? > Note that riscv/arm/arm64 qemu configs *already* override this setting to 512M, as seen in the patch (and so does meta-yocto-bsp/conf/machine/beaglebone-yocto.conf), so this simply brings x86/mips/ppc as well to that level. In our local development we have bumped it even to 2048M, because with 256M there are cryptic boot failures (that have nothing to do with X), and the final SoC target will have far more memory anyway. Embedded does not necessarily mean "not a lot of RAM". If there is a need to test tight-memory scenarios, that can be adjusted per-image (or per-distro like poky-tiny), but I would argue that the default should be such that no one has to stare at mysterious error messages that are ultimately due to lack of RAM. It is not easy to diagnose such situations, e.g. the error message here was "unable to execute xkbcomp", so I had to rebuild the image with strace, and then run X under it to see that the problem was clone() returning with ENOMEM. We'll be surely seeing more of the same as software bloat marches on. Alex
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
