Re: [ck] Re: Faster resuming of suspend technology.

[Pavel Machek <pavel@suse.cz>]

On Po 13-03-06 21:35:59, Con Kolivas wrote:
> On Monday 13 March 2006 21:06, Pavel Machek wrote:
> > On Ne 12-03-06 22:32:28, Andreas Mohr wrote:
> > > And... well... this sounds to me exactly like a prime task
> > > for the newish swap prefetch work, no need for any other
> > > special solutions here, I think.
> > > We probably want a new flag for swap prefetch to let it know
> > > that we just resumed from software suspend and thus need
> > > prefetching to happen *much* faster than under normal
> > > conditions for a short while, though (most likely by
> > > enabling prefetching on a *non-idle* system for a minute).
> >
> > Yep, that would be nice. We are actually able to save up-to half of
> > pagecache, so situation is not as bad as it used to be.
> 
> I would be happy to extend swap prefetch's capabilities to improve
> resume. It 

That would be nice.

> wouldn't be too hard to add a special post_resume_swap_prefetch() which 
> aggressively prefetches for a while. Excuse my ignorance, though, as I know 
> little about swsusp. Are there pages still on swap space after a resume 
> cycle?

Yes, there are, most of the time. Let me explain:

swsusp needs half of memory free. So it shrinks caches (by emulating
memory pressure) so that half of memory if free (and optionaly shrinks
them some more). Pages are pushed into swap by this process.

Now, that works perfectly okay for me (with 1.5GB machine). I can
imagine that on 128MB machine, shrinking caches to 64MB could hurt a
bit. I guess we'll need to find someone interested with small memory
machine (if there are no such people, we can happily ignore the issue
:-).
								Pavel
-- 
61:        uint KeyID = BitConverter.ToUInt32( adKEY, 0 );