From: Pavel Machek <pavel@ucw.cz>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: 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: Thu, 11 May 2006 13:35:19 +0200 [thread overview]
Message-ID: <20060511113519.GB27638@elf.ucw.cz> (raw)
In-Reply-To: <200605110058.19458.rjw@sisk.pl>
On Čt 11-05-06 00:58:18, Rafael J. Wysocki wrote:
> On Wednesday 10 May 2006 00:27, Andrew Morton wrote:
> > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > >
> > > Now if the mapped pages that are not mapped by the
> > > current task are considered, it turns out that they would change only if they
> > > were reclaimed by try_to_free_pages(). Thus if we take them out of reach
> > > of try_to_free_pages(), for example by (temporarily) moving them out of their
> > > respective LRU lists after creating the image, we will be able to include them
> > > in the image without copying.
> >
> > I'm a bit curious about how this is true. There are all sorts of way in
> > which there could be activity against these pages - interrupt-time
> > asynchronous network Tx completion, async interrupt-time direct-io
> > completion, tasklets, schedule_work(), etc, etc.
>
> AFAIK, many of these things are waited for uninterruptibly, and
> uninterruptible
Well, "many of these things" makes me nervous.
> tasks cannot be frozen. Theoretically we may have a problem if there's an
> interruptible task that waits for the completion of an operation that gets
> finished after snapshotting the system.
I'd prefer not to have even theoretical problems. If we don't _know_
why patch is safe, I'd prefer not to have it.
Needing bdev freezing is bad sign, too.
We are talking 10% speedup here (on low-mem-machines, IIRC), but whole
design has just got way more complex. Previous snapshot was really
atomic, and apart from NMI, it was "independend" from the rest of the
system.
New design depends on bdev freezing (depending on XFS details we do
not understand), and depends on all the other parts of kernel using
uninteruptible (when we know that networking sleeps interruptibly).
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?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2006-05-11 11:36 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 [this message]
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
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=20060511113519.GB27638@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
--cc=rjw@sisk.pl \
/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
all inboxes | Powered by JetHome®