Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

From: Pavel Machek
Date: Fri Feb 24 2006 - 19:44:56 EST


On So 25-02-06 10:26:17, Nigel Cunningham wrote:
> Hi.
>
> On Saturday 25 February 2006 10:20, Rafael J. Wysocki wrote:
> > Hi,
> >
> > On Saturday 25 February 2006 00:11, Nigel Cunningham wrote:
> > > On Saturday 25 February 2006 06:22, Rafael J. Wysocki wrote:
> > > > On Friday 24 February 2006 14:12, Pavel Machek wrote:
> > > > > On Pá 24-02-06 11:58:07, Rafael J. Wysocki wrote:

> > > I mean, that only means that the poor system has more pages to fault back
> > > in at resume time, before the user can even begin to think about doing
> > > anything useful.
> >
> > Well, that's not the only possibility. After we fix the memory freeing
> > issue we can use the observation that page cache pages need not be saved to
> > disk during suspend, because they already are in a storage. We only need
> > to create a map of these pages during suspend with the information on where
> > to get them from and prefetch them into memory during resume independently
> > of the page fault mechanism.
> >
> > This way we won't have to actually save anything before we snapshot the
> > system and the system should be reasonably responsive after resume.
>
> But this is going to be much more complicated than simply saving the pages in
> the first place. You'll need some mechanism for figuring out what pages to
> get, how to fault them in, etc. In addition, it will be much slower than
> simply reading them back from (ideally) contiguous storage.

It will not be *much* slower. You gain some speed by not having to
write anything, too. And done properly, it is going to be simple. Lets
see what Rafael comes up with.

[Big advantage is that /proc/list-me-pagecache can be implemented
without any dependencies on the rest of swsusp code, and is likely to
be useful for speeding up boot, etc.]
Pavel
--
Web maintainer for suspend.sf.net (www.sf.net/projects/suspend) wanted...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/