Re: swsusp performance problems in 2.6.15-rc3-mm1

[Nigel Cunningham <ncunningham@cyclades.com>]

Hi.

On Wed, 2005-12-07 at 00:22, Pavel Machek wrote:
> Hi!
> 
> > Hi. Tue, 2005-12-06 at 12:06, Andy Isaacson wrote:
> > > Could we rework it to avoid writing clean pages out to the swsusp image,
> > > but keep a list of those pages and read them back in *after* having
> > > resumed?  Maybe do the /dev/initrd ('less +/once Documentation/initrd.txt'
> > > if you're not familiar with it) trick to make the list of pages available 
> > > to a userland helper.
> > 
> > The problem is that once you let userspace run, you have absolutely no
> > control over what pages are read from or written to, and if a userspace
> > app assumes that data is there in a page when it isn't, you have a
> > recipe for an oops at best, and possibly for on disk
> > corruption. Pages
> 
> No, that will not be a problem. You just resume system as you do now,
> most pages will be not there. *But kernel knows it is not there*, and
> will on-demand load them back. It will be normal userland application
> doing readback. There's absolutely no risk of corruption.

How does the kernel know the pages aren't there? I thought for a while
yesterday that I'd just misread something, but as I look at this again
this morning, I'm not so sure. For what you're talking about to work,
you'd need to mess with the page tables so that the kernel doesn't think
those pages are still there.

I can understand how you'd remember what pages to fault in, but getting
the kernel to know they're not there sounds like a rewrite of kswapd.

Regards,

Nigel

> Imagine something that saves list of needed pages before suspend, then
> does something like
> 
> cat `cat /proc/[0-9]*/maps | grep / | sed 's:.* /:/:' | sort -u` > /dev/null
> 
> ...it should work pretty well. And worst thing it can do is send your
> system thrashing.
> 
> 								Pavel
--