suspend-to-disk

[Jordan Crouse]

On 09/07/07 01:06 -0400, C. Scott Ananian wrote:
> On 7/8/07, Mitch Bradley <wmb at laptop.org> wrote:
> > 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 existing linux suspend-to-disk does this: pages that are
> disk-backed are not duplicated, and dirty pages are written out rather
> than saved dirty.  There is a time penalty for doing this.  Suspend2
> has support for page compression as well (http://www.tuxonice.net/)
> and seems to be fairly mature and under active development, although
> I've only used the stock kernel STD myself.  But it would make sense
> to use the existing suspend2 stuff instead of rolling our own in OFW.
> I've already volunteered in #olpc to write the early userspace
> support, since I seem to have adopted the initramfs (and since I wrote
> the STD stuff in yaird).

I agree - the suspend to disk code in Linux is already quite mature and
ready for use - it only saves the pages it needs to.  The question here
isn't so much how to implement STD, since the concepts are pretty well
understood - but rather, can we implement it on a NAND device without
wasting too much precious storage space while avoiding lifetime issues
on the flash, and do it anywhere fast enough to make it worthwhile
during regular use?  These are questions I know not the answer to.

Jordan

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.