From: Nigel Cunningham <nigel@nigel.suspend2.net>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Pavel Machek <pavel@ucw.cz>, Kyle Moffett <mrmacman_g4@mac.com>,
Matthew Garrett <mjg59@srcf.ucam.org>,
David Chinner <dgc@sgi.com>,
Jeremy Fitzhardinge <jeremy@goop.org>,
xfs-masters@oss.sgi.com,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: freeze vs freezer
Date: Thu, 03 Jan 2008 20:19:36 +1100 [thread overview]
Message-ID: <477CA8A8.2090201@nigel.suspend2.net> (raw)
In-Reply-To: <200801022304.19279.rjw@sisk.pl>
Hi.
Rafael J. Wysocki wrote:
> On Wednesday, 2 of January 2008, Nigel Cunningham wrote:
>> Pavel Machek wrote:
>>>>>>>> So how do you handle threads that are blocked on I/O or a lock
>>>>>>>> during the system freeze process, then?
>>>>>>> We wait until they can continue.
>>>>>> So if I have a process blocked on an unavilable NFS mount, I can't
>>>>>> suspend?
>>>>> That's correct, you can't.
>>>>>
>>>>> [And I know what you're going to say. ;-)]
>>>> Why exactly does suspend/hibernation depend on "TASK_INTERRUPTIBLE"
>>>> instead of a zero preempt_count()? Really what we should do is just
>>>> iterate over all of the actual physical devices and tell each one
>>>> "Block new IO requests preemptably, finish pending DMA, put the
>>>> hardware in low-power mode, and prepare for suspend/hibernate". As
>>>> long as each driver knows how to do those simple things we can have
>>>> an entirely consistent kernel image for both suspend and for
>>>> hibernation.
>>> "each driver" means this is a lot of work. But yes, that is probably
>>> way to go, and patch would be welcome.
>> Yes, that does work. It's what I've done in my (preliminary) support for
>> fuse.
>
> Hmm, can you please elaborate a bit?
Sorry. I wasn't very unambiguous, was I? And I'm not sure now whether
you're meaning "How does fuse support relate to freezing block devices?"
or "What's this about fuse support?". Let me therefore seek to answer
both questions:
Higher level, I know (filesystems rather than block devices), but I was
meaning the general concept of blocking new requests and completing
existing ones worked fine for the supposedly impossible fuse support.
Re fuse support, let me start by saying "I know this doesn't handle all
situations, but I think it's a good enough proof-of-concept implementation".
I added some simple hooks to the code for submitting new work to fuse
threads.
#define FUSE_MIGHT_FREEZE(superblock, desc) \
do { \
int printed = 0; \
while(superblock->s_frozen != SB_UNFROZEN) { \
if (!printed) { \
printk("%d frozen in " desc ".\n", current->pid); \
printed = 1; \
} \
try_to_freeze(); \
yield(); \
} \
} while (0)
On top of this, I made a (too simple at the moment) freeze_filesystems
function which iterates through &super_blocks in reverse order, freezing
fuse filesystems or ordinary ones. I say 'too simple' because it doesn't
currently allow for the possibility of someone mounting (say) ext3 on
fuse, but that would just be an extension of what's already done.
The end result is:
int freeze_processes(void)
{
int error;
printk(KERN_INFO "Stopping fuse filesystems.\n");
freeze_filesystems(FS_FREEZER_FUSE);
freezer_state = FREEZER_FILESYSTEMS_FROZEN;
printk(KERN_INFO "Freezing user space processes ... ");
error = try_to_freeze_tasks(FREEZER_USER_SPACE);
if (error)
goto Exit;
printk(KERN_INFO "done.\n");
sys_sync();
printk(KERN_INFO "Stopping normal filesystems.\n");
freeze_filesystems(FS_FREEZER_NORMAL);
freezer_state = FREEZER_USERSPACE_FROZEN;
printk(KERN_INFO "Freezing remaining freezable tasks ... ");
error = try_to_freeze_tasks(FREEZER_KERNEL_THREADS);
if (error)
goto Exit;
printk(KERN_INFO "done.");
freezer_state = FREEZER_FULLY_ON;
Exit:
BUG_ON(in_atomic());
printk("\n");
return error;
}
Sorry if that's more info than you wanted.
Nigel
next prev parent reply other threads:[~2008-01-03 9:19 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-22 3:54 freeze vs freezer Jeremy Fitzhardinge
2007-11-23 23:47 ` Rafael J. Wysocki
2007-11-26 18:44 ` Jeremy Fitzhardinge
2007-11-26 21:20 ` Rafael J. Wysocki
2007-11-26 21:17 ` David Chinner
2007-11-26 21:53 ` Rafael J. Wysocki
2007-11-27 5:38 ` Matthew Garrett
2007-11-27 17:40 ` Rafael J. Wysocki
2007-11-27 20:33 ` Kyle Moffett
2007-11-27 23:01 ` Rafael J. Wysocki
2007-11-27 22:49 ` Jeremy Fitzhardinge
2007-11-27 23:14 ` Kyle Moffett
2007-11-27 23:32 ` Jeremy Fitzhardinge
2008-01-02 16:02 ` Pavel Machek
2008-01-02 21:30 ` Nigel Cunningham
2008-01-02 22:04 ` Rafael J. Wysocki
2008-01-03 9:19 ` Nigel Cunningham [this message]
2008-01-03 9:47 ` Oliver Neukum
2008-01-03 9:52 ` Nigel Cunningham
2008-01-03 11:15 ` Oliver Neukum
2008-01-03 22:06 ` Nigel Cunningham
2008-01-04 20:54 ` Oliver Neukum
2008-01-05 1:38 ` Kyle Moffett
2008-01-05 21:18 ` Pavel Machek
2008-01-05 23:01 ` Nigel Cunningham
2008-01-03 22:31 ` Rafael J. Wysocki
2008-06-23 7:16 ` Pavel Machek
2008-06-23 14:00 ` Henrique de Moraes Holschuh
2008-06-24 8:08 ` Elias Oltmanns
2008-06-26 15:09 ` Pavel Machek
2008-06-29 22:12 ` [xfs-masters] " Dave Chinner
2008-06-29 23:22 ` Rafael J. Wysocki
2008-06-30 6:11 ` Christoph Hellwig
2008-06-30 20:34 ` Rafael J. Wysocki
2008-07-03 19:43 ` Eric Sandeen
2008-06-30 6:29 ` Dave Chinner
2008-06-30 6:37 ` Jeremy Fitzhardinge
2008-06-30 12:33 ` Dave Chinner
2008-06-30 21:00 ` Rafael J. Wysocki
2008-06-30 22:21 ` Dave Chinner
2008-06-30 22:38 ` Rafael J. Wysocki
2008-07-01 6:38 ` Dave Chinner
2008-07-01 14:35 ` Rafael J. Wysocki
2008-07-01 15:05 ` Elias Oltmanns
2008-07-01 15:17 ` Christoph Hellwig
2008-07-01 21:15 ` Dave Chinner
2008-07-01 21:46 ` Elias Oltmanns
2008-07-01 21:12 ` Dave Chinner
2008-07-01 21:21 ` Rafael J. Wysocki
2008-07-01 8:59 ` Pavel Machek
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=477CA8A8.2090201@nigel.suspend2.net \
--to=nigel@nigel.suspend2.net \
--cc=dgc@sgi.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=mrmacman_g4@mac.com \
--cc=pavel@ucw.cz \
--cc=rjw@sisk.pl \
--cc=xfs-masters@oss.sgi.com \
/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