From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Andy Isaacson <adi@hexapodia.org>
Cc: linux-kernel@vger.kernel.org, Pavel Machek <pavel@ucw.cz>
Subject: Re: swsusp performance problems in 2.6.15-rc3-mm1
Date: Tue, 6 Dec 2005 00:05:04 +0100 [thread overview]
Message-ID: <200512060005.04556.rjw@sisk.pl> (raw)
In-Reply-To: <20051205081935.GI22168@hexapodia.org>
Hi,
On Monday, 5 December 2005 09:19, Andy Isaacson wrote:
> On recent kernels such as 2.6.14-rc2-mm1, a swsusp of my laptop (1.25
> GB, P4M 1.4 GHz) was a pretty fast process; freeing memory took about 3
> seconds or less,
It took much more time on my box, but I won't discuss with your
experience. ;-)
> and writing out the swap image took less than 5
> seconds, so within 15 seconds of running my suspend script power was
> off.
>
> The downside was that after suspend, *everything* needed to be paged
> back in, so all my apps were *very* slow for the first few interactions.
> It would take about 15 or 20 seconds for Firefox to repaint the first
> time I switched to its virtual desktop, and it was perceptibly slower
> than normal for the next 5 or 10 minutes of use.
>
> Now that I'm running 2.6.15-rc3-mm1, the page-in problem seems to be
> largely gone; I don't notice a significant lagginess after resuming from
> swsusp.
>
> But the suspend process is *slow*. It takes a good 20 or 30 seconds to
> write out the image, which makes the overall suspend process take close
> to a minute; it's writing about 400 MB, and my disk seems to only be
> good for about 18 MB/sec according to hdparm -t.
>
> And, the resume is about the same amount slower, too.
>
> Certainly there's a tradeoff to be made, and I'm glad to lose the slow
> re-paging after resume, but I'm hoping that some kind of improvement can
> be made in the suspend/resume time.
Yes, there is a tradeoff. Till now, we have used the simplistic approach
based on freeing as much memory as possible before suspend. Now, we
are freeing only as much memory as necessary, which is on the other
end of the scale, so to speak. There are a whole lot of possibilities in
between, and there's a question which one is the best. Frankly, I'm afraid
the answer is very system-dependent.
If you want a quick solution, you can get back to the previous behavior by
commenting out the definition of FAST_FREE in kernel/power/power.h.
Alternatively, you can increase the value of PAGES_FOR_IO, defined
in include/linux/suspend.h. To see any effect, you'll probably have to
increase it by tens of thousands, but please note the box may be unable
to suspend if it's too great (if you try this anyway, please let me know what
number seems to be the best to you).
Also, I can create a patch to improve this a bit, if you promise to help
test/debug it. ;-)
Greetings,
Rafael
--
Beer is proof that God loves us and wants us to be happy - Benjamin Franklin
next prev parent reply other threads:[~2005-12-05 23:25 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-05 8:19 swsusp performance problems in 2.6.15-rc3-mm1 Andy Isaacson
2005-12-05 12:17 ` Pavel Machek
2005-12-05 13:58 ` Nigel Cunningham
2005-12-05 17:29 ` Pavel Machek
2005-12-05 21:11 ` Nigel Cunningham
2005-12-05 23:34 ` Pavel Machek
2005-12-06 1:26 ` Nigel Cunningham
2005-12-06 1:52 ` Pavel Machek
2005-12-05 22:44 ` Rafael J. Wysocki
2005-12-06 0:01 ` Pavel Machek
2005-12-05 22:28 ` Rafael J. Wysocki
2005-12-06 1:07 ` Nigel Cunningham
2005-12-06 1:37 ` Pavel Machek
2005-12-06 1:47 ` Andy Isaacson
2005-12-06 1:56 ` IDE performance on notebooks [was Re: swsusp performance problems in 2.6.15-rc3-mm1] Pavel Machek
2005-12-06 6:23 ` Andy Isaacson
2005-12-06 11:56 ` Pavel Machek
2005-12-06 1:57 ` swsusp performance problems in 2.6.15-rc3-mm1 Nigel Cunningham
2005-12-06 3:50 ` Mark Lord
2005-12-06 15:03 ` Mark Lord
2005-12-06 2:02 ` Nigel Cunningham
2005-12-06 12:09 ` Pavel Machek
2005-12-06 1:36 ` Nigel Cunningham
2005-12-06 2:06 ` Andy Isaacson
2005-12-06 2:21 ` Nigel Cunningham
2005-12-06 14:22 ` Pavel Machek
2005-12-07 22:05 ` Nigel Cunningham
2005-12-07 22:23 ` Pavel Machek
2005-12-06 2:21 ` Nigel Cunningham
2005-12-06 12:18 ` Pavel Machek
2005-12-06 18:15 ` Andy Isaacson
2005-12-07 1:05 ` Rafael J. Wysocki
2005-12-07 1:10 ` Pavel Machek
2005-12-07 11:17 ` Rafael J. Wysocki
2005-12-07 11:30 ` Pavel Machek
2005-12-08 22:42 ` Rafael J. Wysocki
2005-12-08 22:50 ` Pavel Machek
2005-12-05 21:18 ` Rafael J. Wysocki
2005-12-05 23:55 ` swsusp: how much memory to free? [was Re: swsusp performance problems in 2.6.15-rc3-mm1] Pavel Machek
2005-12-07 11:53 ` Rafael J. Wysocki
2005-12-07 11:59 ` Pavel Machek
2005-12-07 12:16 ` Rafael J. Wysocki
2005-12-07 12:18 ` Pavel Machek
2005-12-05 23:05 ` Rafael J. Wysocki [this message]
2005-12-06 0:12 ` swsusp performance problems in 2.6.15-rc3-mm1 Andy Isaacson
2005-12-06 0:51 ` Pavel Machek
2005-12-10 22:21 ` Andrew Morton
2005-12-10 23:07 ` Rafael J. Wysocki
2005-12-10 23:33 ` Andrew Morton
2005-12-11 12:16 ` Rafael J. Wysocki
2005-12-11 23:28 ` Pavel Machek
2005-12-12 17:45 ` 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=200512060005.04556.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=adi@hexapodia.org \
--cc=linux-kernel@vger.kernel.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