[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200707101133.01566.nigel@nigel.suspend2.net>
Date: Tue, 10 Jul 2007 11:33:00 +1000
From: Nigel Cunningham <nigel@...el.suspend2.net>
To: "Rafael J. Wysocki" <rjw@...k.pl>
Cc: Pavel Machek <pavel@....cz>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Alan Stern <stern@...land.harvard.edu>,
Kyle Moffett <mrmacman_g4@....com>,
Matthew Garrett <mjg59@...f.ucam.org>,
linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org,
Miklos Szeredi <miklos@...redi.hu>
Subject: Re: hibernation/snapshot design [was Re: [PATCH] Remove process freezer from suspend to RAM pathway]
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.
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists