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

From: Rafael J. Wysocki
Date: Tue Feb 21 2006 - 15:34:01 EST


Hi,

On Tuesday 21 February 2006 12:33, Pavel Machek wrote:
> On Po 20-02-06 20:32:25, Andy Lutomirski wrote:
> > Matthias Hensler wrote:
> > >On Mon, Feb 20, 2006 at 01:53:33AM +0100, Pavel Machek wrote:
> > >
> > >>Only feature I can't do is "save whole pagecache"... and 14000 lines
> > >>of code for _that_ is a bit too much. I could probably patch my kernel
> > >>to dump pagecache to userspace, but I do not think it is worth the
> > >>effort.
> > >
> > >
> > >I do not think that Suspend 2 needs 14000 lines for that, the core is
> > >much smaller. But besides, _not_ saving the pagecache is a really _bad_
> > >idea. I expect to have my system back after resume, in the same state I
> > >had left it prior to suspend. I really do not like it how it is done by
> > >Windows, it is just ugly to have a slowly responding system after
> > >resume, because all caches and buffers are gone.
> > >
> > >I can only speak for myself, but I want to work with my system from the
> > >moment my desktop is back.
> >
> > I Am Not A VM Hacker, but:
> >
> > What's the point of saving pagecache during suspend? This seems like a
> > total waste. Why don't we save a list of pages in pagecache to disk,
> > then, after resume, prefetch them all back in. This will slow down
> > resume (extra seeks, minimized if we sort the list, and inability
> > to compress these pages), but it will speed up suspend, and it sounds
> > a lot simpler. There's already a patch to add swap prefetching, and
> > this can't be much more complicated.
>
> I'd actually love to see this implemented. It would be useful for
> suspend-to-disk (obviously), but also for benchmarks.

Actually I've been thinking of something similar for some time,
so perhaps we should add this to the todolist somewhere? ;-)

Rafael
-
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/