Re: [PATCH][3/3] mm: swsusp post resume aggressive swap prefetch

[Rafael J. Wysocki]

On Monday 20 March 2006 22:25, kernel@xxxxxxxxxxx wrote:
> Quoting "Rafael J. Wysocki" <rjw@xxxxxxx>:
> 
> > Hi,
> > 
> > On Sunday 19 March 2006 16:34, Con Kolivas wrote:
> > > 
> > > Swsusp reclaims a lot of memory during the suspend cycle and can benefit
> > > from the aggressive_swap_prefetch mode immediately upon resuming.
> > 
> > It slows down the resume on my box way too much.  Last time it took 10x more
> > time than actually reading the image.
> > 
> > I think the problem is for the userland suspend (which I use) it's done too
> > early,
> > when the image pages are still in the swap, so they are taken into
> > consideration
> > by the aggressive prefetch.  If that really is the case, the solution would
> > be to
> > trigger the aggressive prefetch from the userland, if needed, after the
> > image
> > pages have been released.
> 
> I assume this is unique to the userland resume as the in-kernel resume is not
> slowed down?

Sorry, I was wrong.  After resume the image pages in the swap are visible as
free, because we allocate them after we have created the image (ie. the image
contains the system state in which these pages are free).

Well, this means I really don't know what happens and what causes the
slowdown.  It certainly is related to the aggressive prefetch hook in
swsusp_suspend().  [It seems to search the whole swap, but it doesn't
actually prefetch anything.  Strange.]

> If so, is there a way to differentiate the two so we only aggressively
> prefetch on kernel resume - is that what you meant by doing it in the
> other file? 

Basically, yes.  swsusp.c and snapshot.c contain common functions,
disk.c and swap.c contain the code used by the built-in swsusp only,
and user.c contains the userland interface.  If you want something to
be run by the built-in swsusp only, place it in disk.c.

Still in this particular case it won't matter, I'm afraid.

Greetings,
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/