[OE-core] [PATCH 2/3] qemuboot.bbclass: increase the default RAM to 512M
Alexander Kanavin
alex.kanavin at gmail.com
Wed Aug 14 17:24:30 UTC 2019
On Wed, 14 Aug 2019 at 18:42, Richard Purdie <
richard.purdie at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20190814/4a5bd336/attachment.html>
More information about the Openembedded-core
mailing list