From: Andrew Morton <akpm@osdl.org>
To: Nigel Cunningham <ncunningham@linuxmail.org>
Cc: rjw@sisk.pl, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Thaw userspace and kernel space separately.
Date: Mon, 23 Oct 2006 09:51:24 -0700 [thread overview]
Message-ID: <20061023095124.7be583ce.akpm@osdl.org> (raw)
In-Reply-To: <1161604811.3315.12.camel@nigel.suspend2.net>
> On Mon, 23 Oct 2006 22:00:11 +1000 Nigel Cunningham <ncunningham@linuxmail.org> wrote:
> Hi.
>
> On Mon, 2006-10-23 at 12:26 +0200, Rafael J. Wysocki wrote:
> > On Monday, 23 October 2006 01:48, Nigel Cunningham wrote:
> > > Modify process thawing so that we can thaw kernel space without thawing
> > > userspace, and thaw kernelspace first. This will be useful in later
> > > patches, where I intend to get swsusp thawing kernel threads only before
> > > seeking to free memory.
> >
> > Please explain why you think it will be necessary/useful.
> >
> > I remember a discussion about it some time ago that didn't indicate
> > we would need/want to do this.
>
> This is needed to make suspending faster and more reliable when the
> system is in a low memory situation. Imagine that you have a number of
> processes trying to allocate memory at the time you're trying to
> suspend. They want so much memory that when you come to prepare the
> image, you find that you need to free pages. But your swapfile is on
> ext3, and you've just frozen all processes, so any attempt to free
> memory could result in a deadlock while the vm tries to swap out pages
> using the frozen kjournald. So you need to thaw processes to free the
> memory. But thawing processes will start the processes allocating memory
> again, so you'll be fighting an uphill battle.
>
> If you can only thaw the kernel threads, you can free memory without
> restarting userspace or deadlocking against a frozen kjournald.
>
kjournald will not participate in writing to swapfiles.
The situation where we would need this feature is where the loop driver is
involved in the path-to-disk. But I doubt if that's a thing we'd want to
support.
otoh there may be other kernel threads which are a saner thing to have in
the swapout path and which we do want to support. md_thread, perhaps?
next prev parent reply other threads:[~2006-10-23 16:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-22 23:48 [PATCH] Thaw userspace and kernel space separately Nigel Cunningham
2006-10-23 10:26 ` Rafael J. Wysocki
2006-10-23 12:00 ` Nigel Cunningham
2006-10-23 13:41 ` Rafael J. Wysocki
2006-10-23 16:51 ` Andrew Morton [this message]
2006-10-23 18:37 ` Rafael J. Wysocki
2006-10-25 17:45 ` dean gaudet
2006-10-23 15:18 ` Pavel Machek
2006-10-29 0:04 ` Bill Davidsen
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=20061023095124.7be583ce.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ncunningham@linuxmail.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.