From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Pavel Machek <pavel@suse.cz>
Cc: Nigel Cunningham <ncunningham@cyclades.com>,
Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, nickpiggin@yahoo.com.au
Subject: Re: [PATCH -mm] swsusp: support creating bigger images (rev. 2)
Date: Sun, 14 May 2006 00:33:14 +0200 [thread overview]
Message-ID: <200605140033.14967.rjw@sisk.pl> (raw)
In-Reply-To: <20060512103013.GG28232@elf.ucw.cz>
Hi,
Sorry for the slow response, I've had a lot of work to do recently.
On Friday 12 May 2006 12:30, Pavel Machek wrote:
> > > Too much uncertainity for 10% speedup, I'm afraid. Yes, it was really
> > > clever to get this fundamental change down to few hundred lines, but
> > > design complexity remains. Could we drop that patch?
I think the main problem with the patch was that the criterion by which
the pages were included in the image without copying appeared to be too simple
and therefore too general. It well might be correct, but that's yet to be
shown. OTOH it probably is possible to use a criterion that everybody will
agree with. For example, we could chose pages that would be reclaimed if
there were memory pressure (the pages with I/O operations pending should
not belong to this class).
> > Could you provide justification for your claim that the speedup is
> > only 10%?
>
> 10% was number Rafael provided, IIRC.
That's true, but I only measured the short-time effect of the suspend on the
system responsiveness.
Apart from this without the patch swsusp tends to leave quite o lot
of data in the swap and IMO this effect should not be neglected. Currently we
only have a very general idea about what these data are and why it happens
actually and there's no warranty it wouldn't hamper performance in the
long run.
> > Please also remember that you are introducing complexity in other ways, with
> > that swap prefetching code and so on. Any comparison in speed should include
> > the time to fault back in pages that have been discarded.
>
> Well, swap prefetching is useful for other workloads, too; so it gets
> developed/tested outside swsusp.
Still my experience indicates that it doesn't play very nice with swsusp and
unfortunately it hogs the I/O.
Greetings,
Rafael
next prev parent reply other threads:[~2006-05-13 22:33 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-02 10:00 [PATCH -mm] swsusp: support creating bigger images Rafael J. Wysocki
2006-05-09 7:33 ` Andrew Morton
2006-05-09 10:19 ` Rafael J. Wysocki
2006-05-09 11:22 ` Pavel Machek
2006-05-09 12:18 ` Rafael J. Wysocki
2006-05-09 12:30 ` Hugh Dickins
2006-05-10 3:50 ` Nick Piggin
2006-05-10 22:26 ` Rafael J. Wysocki
2006-05-11 15:01 ` Hugh Dickins
2006-05-11 21:19 ` Rafael J. Wysocki
2006-05-09 22:15 ` [PATCH -mm] swsusp: support creating bigger images (rev. 2) Rafael J. Wysocki
2006-05-09 22:27 ` Andrew Morton
2006-05-10 22:58 ` Rafael J. Wysocki
2006-05-10 23:38 ` Andrew Morton
2006-05-11 0:11 ` Nigel Cunningham
2006-05-11 13:20 ` Rafael J. Wysocki
2006-05-11 23:45 ` Nigel Cunningham
2006-05-12 0:17 ` Nathan Scott
2006-05-12 10:09 ` Pavel Machek
2006-05-13 22:32 ` Rafael J. Wysocki
2006-05-11 13:15 ` Rafael J. Wysocki
2006-05-11 11:35 ` Pavel Machek
2006-05-11 12:10 ` Rafael J. Wysocki
2006-05-11 23:49 ` Nigel Cunningham
2006-05-12 10:30 ` Pavel Machek
2006-05-13 22:33 ` Rafael J. Wysocki [this message]
2006-05-15 9:48 ` Con Kolivas
2006-05-15 19:52 ` Rafael J. Wysocki
2006-05-15 23:50 ` Con Kolivas
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=200605140033.14967.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ncunningham@cyclades.com \
--cc=nickpiggin@yahoo.com.au \
--cc=pavel@suse.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
Powered by JetHome