From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, nickpiggin@yahoo.com.au, pavel@suse.cz
Subject: Re: [PATCH -mm] swsusp: support creating bigger images (rev. 2)
Date: Thu, 11 May 2006 00:58:18 +0200 [thread overview]
Message-ID: <200605110058.19458.rjw@sisk.pl> (raw)
In-Reply-To: <20060509152713.36bb94f0.akpm@osdl.org>
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
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. However that would have to survive the
syncing of filesystems, freezing of kernel threads, freeing of memory as well
as suspending and resuming all devices. [In which case it would be starving
to death. :-)]
Greetings,
Rafael
next prev parent reply other threads:[~2006-05-10 22:58 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 [this message]
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
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=200605110058.19458.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--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
all inboxes | Powered by JetHome®