Track available RAM in hardware packs

Changing description to better describe the bug and moving to Linaro.

CONFIG_SWAP is on in kernel so not a kernel bug.

The only fix I can see for this is to make sure linaro-media-create is always creating a swapfile when installing to certain known low-memory targets. We can do that one of two ways; we can make a default swap size part of the board config info (and have an override command-line option to disable, perhaps --no-swap?), or we can just update the documentation to mention how much memory is needed for a given image to run and expect users to set appropriate swap themselves. Reassigning to linaro-image-tools for consideration of the first option.

(BTW, Tom, was there any particular evidence that fsck.ext3 was using more memory than reasonable here? Perhaps we should also be filing a bug task against e2fsprogs.)

In an ideal world, we could document the RAM requirements of an image (like headless or ubuntu-netbook) and the size of RAM of the targeted board in a hwpack, and use these information to decide the size of the swap. Adding swap might not sound complex, but it can either be a swap file or a separate partition, we will have to align the partition properly, mkswap it, lookup its UUID etc., things close to what we do.

In the mean time, I recommend that we document expected RAM requirements for each image, and request people to decide whether they need to pass --swap-size.

I've added the ram_size informational field to the hardware packs v2 spec.

Jamie will amend the documentation to mention that --swap_size should definitely be passed for some images; I'm keeping a bug task open for the hardware pack v2 ram_size implementation.

Ideally, we'd also have a better rootfs format to carry meta information such as required RAM size, but we don't have any plans for this yet -- do we want a bug for this?

Tom, can you confirm that passing "--swap_size somethinglarge" to linaro-media-create fixes this?

Also, which specific error from your dmesg was this about? there are multiple ones

PS: please include all the information in the bug itself, perhaps as a dmesg attachment, rather than linking to a pastebin which might go away

On Tue, 01 Feb 2011 14:01:05 -0000, Loïc Minier <email address hidden> wrote:
> Jamie will amend the documentation to mention that --swap_size should
> definitely be passed for some images; I'm keeping a bug task open for
> the hardware pack v2 ram_size implementation.

Does this really belong in the hwpack? What do we do when a hwpack is
shared between two boards with differing amounts of RAM?

Thanks,

James

It hadn't realized that hwpacks could be shared between boards; this doesn't seem like a good idea to me as it means we need multiple version of the metadata: which fdt to use, which board name we mean, which u-boot to use etc.

Peter gave the example of beagle vs beagle XM as boards supported with same u-boot etc. but differing amounts of RAM

I can also think that some boards have variable amounts of RAM (e.g. DDR) so doesn't sound like a good idea to handle this in hwpack v2 indeed.

On Tue, Feb 01, 2011 at 02:39:17PM -0000, James Westby wrote:
> On Tue, 01 Feb 2011 14:01:05 -0000, Loïc Minier <email address hidden> wrote:
> > Jamie will amend the documentation to mention that --swap_size should
> > definitely be passed for some images; I'm keeping a bug task open for
> > the hardware pack v2 ram_size implementation.

> Does this really belong in the hwpack?

Where else could we put it?

> What do we do when a hwpack is shared between two boards with differing
> amounts of RAM?

Use the more conservative figure for available RAM and create larger swap by
default?

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world

> > Does this really belong in the hwpack?
>
> Where else could we put it?

Nowhere? I'm really just exploring the requirements here.

> > What do we do when a hwpack is shared between two boards with differing
> > amounts of RAM?
>
> Use the more conservative figure for available RAM and create larger swap by
> default?

Why not create some amount of swap by default and not try and tailor it
to the boards?

Thanks,

James

On Tue, Feb 01, 2011 at 05:06:36PM -0000, James Westby wrote:
> > > What do we do when a hwpack is shared between two boards with differing
> > > amounts of RAM?

> > Use the more conservative figure for available RAM and create larger swap by
> > default?

> Why not create some amount of swap by default and not try and tailor it
> to the boards?

No good reason, I guess. We would want to make sure we take into account
the target media size, though, to avoid filling up the media. (Probably
relevant for ALIP and nano images in particular which will target contexts
where there's not a lot of disk space available.)

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Removing milestone as this bug currently doesn't have a clear path forward

So in general I don't think its a big problem to rely on our user audience making a wise decision about selecting swap or not.

If we do something we should only warn about a potential unwise decision and not make automatic decisions on swap etc.

I guess there are various ways this could be done as part of hwpackv2 effort.

One way I would be supportive of is to ship a list of board aliases in hwpack; each alias could have its own meta info for some keys, basically overloading the default. For multi board hwpacks, user could then select the exact (known) board name and would get reasonable warnings based on the known memory setup etc.

For boards we don't know yet, there would be a beagle-generic default alias or something.

In turn images need kind of meta info as well about requirements (e.g. require x11 driver, require 512m, etc.)

Due to the age of this issue, we are acknowledging that this issue will likely not be fixed, is no longer applicable, or was already fixed by an indirect change. If this issue is still important, please add details and reopen the issue.