suspend-to-disk

[Walter Bender]

In any analysis, please don't bother with the B1 and B2 configurations
as those platform profiles will not be an option in the production
machines.

-walter

On 7/8/07, Mitch Bradley <wmb at laptop.org> wrote:
> Andres Salomon wrote:
> > ...
> >
> > Implementation questions:
> >
> > I'm not going to concern myself with our B1s, for they have more ram
> > and less nand.  Our B2s have 128MB of ram, and 512MB of nand; B3s and
> > up have 256MB of ram, and 1GB of nand.  We need to figure out just
> > how much space we'd need to set aside in a snapshot partition for STD.
> > I'm not sure what would be required from the OFW side; Mitch?
>
> First-order swag:
>
> You need 256MB of disk to store 256MB of RAM, in the nothing-fancy scenario.
>
> Second-order swag:
>
> Machine code compresses about 2:1 with gzip, so if the memory were full
> of code, you would need about 128MB of disk for 256 MB of RAM.  OFW
> already includes a gunzip-compatible decompressor which is reasonably
> fast (written in C, runs from cached memory).  It would be easy enough
> to add either LZMA , LZO, or QuickLZ.  It's likely that we could overlap
> the compression/decompression with NAND access, so the speed penalty
> would be minimal.
>
> Third-order swag:
>
> The memory is likely to be significantly more compressible than random
> machine code, due to the likely prevalence of sparsely-encoded data.  So
> maybe the average compression in practice would be 3:1 or 4:1 or even
> better.  But we would might need to allocate space for the worst case.
>
> Fourth-order swag:
>
> It wouldn't be necessary to save read-only code ("text" pages) to the
> save area; just mark those pages "not present" and save the information
> necessary to page them back in.  But that would probably make the resume
> slower, because of the JFFS2 operations necessary to resolve all those
> page-in references.  The firmware part of the resume would be faster,
> but the overall suspend/resume process might take longer (or maybe not;
> you trade not having to write the data out on the way down for having to
> do more work on the way up).
>
> The firmware part of this shouldn't be particularly difficult if we can
> make the save format reasonably straighforward.  It could get more
> difficult if we run into enough examples of "somebody has already done
> this so we have to use their existing solution even though it is massive
> overkill for our situation".
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>


-- 
Walter Bender
One Laptop per Child
http://laptop.org