Re: hibernation/snapshot design [was Re: [PATCH] Remove process freezer from suspend to RAM pathway]

[Nigel Cunningham <nigel@nigel.suspend2.net>]

[-- Attachment #1: Type: text/plain, Size: 3168 bytes --]

Hi.

On Monday 09 July 2007 09:01:27 Rafael J. Wysocki wrote:
> Hi,
> 
> On Monday, 9 July 2007 00:13, Pavel Machek wrote:
> > Hi!
> > 
> > > > Actaully, I'm perfectly fine with that, as long as each task blocked 
by the
> > > > driver due to suspend has PF_FROZEN (or something similar) set.  Then, 
at
> > > > least theoretically, we'll be able to drop the freezer from the 
suspend code
> > > > path and move it after device_suspend() (or the hibernation-specific
> > > > equivalent) for hibernation (in that case there shouldn't be a problem 
with
> > > > any task waiting on I/O while the freezer is running ;-)).
> > > 
> > > I don't see the need for a freezer for snapshot but that's a different
> > > issue. (stop_machine looks good enough to me).
> > 
> > Freezer is not needed for snapshot -- it is needed so that we can
> > write out the snapshot to disk without the need for special
> > drivers/block/simple-ide-for-suspend.c. (We are doing snapshot, then
> > write to disk from userland code in uswsusp).
> 
> Yes.
> 
> BTW, this patch:
> 
> 
http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc7/patches/15-freezer-make-kernel-threads-nonfreezable-by-default.patch
> 
> that's queued up in -mm contains a freezer documentation update, in which 
the
> reasons of using it, as well as its limitations, are described.
> 
> To summarize what was previously said in this thread:
> 
> * Apparently, we agree that the freezer is _generally_ not needed for 
suspend
>   (ie. any transition to a system sleep state other than hibernation), but 
some
>   of us (eg. me) think that it wouldn't be reasonable to drop the freezer 
from
>   the suspend code path _right_ _now_ .
> 
> * Some of us, including you, Nigel and me, think that the freezer is needed
>   for hibernation (please see the document in the patch above for details).
>   In the (very) long run this might be avoided too, but (IMO) certainly not 
at
>   this point.
> 
> * We seem to agree that in order to remove the freezer from the suspend code
>   path some work needs to be done on device drivers, driver midlayers and 
the
>   PM core.  We also need to do some work on the PM core in order to 
introduce
>   a separate hibernation framework and IMO it would be reasonable to
>   synchronize these efforts.
> 
> * We are now to decide what to do so that the freezer can be safely removed
>   from the suspend code path and how to integrate that change with the
>   hibernation code path (if possible and reasonable).
> 
> * The freezer vs FUSE issue that started this thread remains unresolved, so
>   it would be desirable to provide a short-term fix (need not be very nice).

(Finally catching up on emails since Saturday!)

The freezer is also essential for doing a full image of memory - you have to 
be able to guarantee that some of the image won't change in order to be able 
to write it out before the atomic copy. Of course the freezer alone isn't 
enough, but it solves 95% of the issue.

Regards,

Nigel
-- 
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]