linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: kernel@kolivas.org
Cc: linux list <linux-kernel@vger.kernel.org>,
	ck list <ck@vds.kolivas.org>, Andrew Morton <akpm@osdl.org>,
	Pavel Machek <pavel@ucw.cz>,
	linux-mm@kvack.org
Subject: Re: [PATCH][3/3] mm: swsusp post resume aggressive swap prefetch
Date: Tue, 21 Mar 2006 00:22:31 +0100	[thread overview]
Message-ID: <200603210022.32985.rjw@sisk.pl> (raw)
In-Reply-To: <1142889937.441f1dd19e90f@vds.kolivas.org>

On Monday 20 March 2006 22:25, kernel@kolivas.org wrote:
> Quoting "Rafael J. Wysocki" <rjw@sisk.pl>:
> 
> > 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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2006-03-20 23:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-19 15:34 Con Kolivas
2006-03-20 21:47 ` Rafael J. Wysocki
2006-03-20 21:25   ` kernel
2006-03-20 23:22     ` Rafael J. Wysocki [this message]
2006-03-21  0:44       ` kernel
2006-03-21 18:11         ` Rafael J. Wysocki
2006-03-22  6:11           ` Con Kolivas
2006-03-24  5:00       ` [PATCH] swswsup: return correct load_image error Con Kolivas
2006-03-24  5:17         ` Con Kolivas
2006-03-24 15:05           ` Rafael J. Wysocki
2006-03-24 14:51         ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200603210022.32985.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=akpm@osdl.org \
    --cc=ck@vds.kolivas.org \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pavel@ucw.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox