Re: Hibernation Redesign

[Nigel Cunningham]

Hi.

On Thursday 12 July 2007 09:12:24 Al Boldi wrote:
> Rafael J. Wysocki wrote:
> > On Thursday, 12 July 2007 00:17, Al Boldi wrote:
> > > Mark Lord wrote:
> > > > Jeremy Maitin-Shepard wrote:
> > > > > I'll certainly admit the kexec idea is vaporware currently,
> > >
> > > Your idea is starting to become a reality with this thread:
> > > "[PATCH 0/2] Kexec jump: The first step to kexec base hibernation"
> > >
> > > > > but it does
> > > > > differ in a significant way from freezer-based approaches, such that
> > > > > I don't think it should be referred to as just another
> > > > > implementation of a freezer.  Specifically, it doesn't require that
> > > > > the "old kernel" be in a "consistent" state to a greater extent than
> > > > > suspend to ram; it is the case that all of the devices must be
> > > > > quiesced or shut down to some extent, but doing this without races
> > > > > and deadlocks (and without the freezer) is certainly very, very
> > > > > similar to what needs to be done for suspend to ram, which will need
> > > > > to be solved anyway.  Unlike the existing hibernate approaches,
> > > > > however, it will not be necessary to use any of the driver
> > > > > infrastructure once switched to the "save image" kernel, and thus it
> > > > > will not matter what locks are held, for instance.
> > > >
> > > > I really doubt that kexec(a special kernel) is going to solve anything
> > > > here. The new kernel will have to initialize, probe for devices, etc.
> > > > Which will take time.
> > > > Which will slow down hibernate to an unacceptable degree.
> > > > Right now, it (TuxOnIce) is *very* fast.
> > > > Adding 10 seconds or so for reprobing/resetting/reiniting devices
> > > > is not going to be useful.
> > > > And modifying all of the drivers to *not* do their usual probe
> > > > sequence sounds rather intrusive and is likely also a non-starter
> > > > here.
> > > >
> > > > Or is it?
> > >
> > > Well, it's definitely less intrusive than readying drivers for the
> > > freezer.
> >
> > There's nothing like this!
> 
> Are you sure?
> 
> # grep -i freeze drivers/*/* | wc -l
> 
> gives:  297
> 
> Maybe you can clarify?

Rafael's probably just gone to sleep, so let me be so bold as to give an 
answer.

First, you need to understand that there is a difference between the process 
freezer and driver support for suspending and resuming. The two are 
completely unrelated. Process freezing happens at the start of a hibernation 
cycle. Driver suspend and resume calls happen prior to and after an atomic 
copy or restore. Process freezing stops processes. Driver suspend and resume 
calls tell drivers to save their state and possibly enter low power modes. 
Process freezing isn't a necessary prerequisite for calling driver 
suspend/resume routines. (That has been the point to discussions about 
suspend to ram).

Since this is the case, doing grep -i freeze drivers/*/* is a bogus test. If 
you want to look for drivers using the freezer, you need to grep for 
try_to_freeze and PF_NOFREEZE. PF_NOFREEZE says the related kernel thread 
shouldn't be frozen (11 hits in the source tree I'm looking at). Grepping for 
try_to_freeze gets 29. By the way, find drivers/ -name '*.[ch]' | xargs grep 
try_to_freeze (for example) is a better search - it isn't dependant upon the 
number of subdirectories.

You'll see from the above numbers that the freezer is not nearly as intrusive 
as you were thinking (~10% of what you wrote above). It is limited to code 
related to kernel threads, and then to either setting a flag when the thread 
is started to say "I don't need to be frozen" or to the appropriate point at 
which to check whether to freeze.

Hope that helps.

Nigel
-- 
Nigel Cunningham
Christian Reformed Church of Cobden
103 Curdie Street, Cobden 3266, Victoria, Australia
Ph. +61 3 5595 1185 / +61 417 100 574
Communal Worship: 11 am Sunday.

Attachment: pgp00000.pgp
Description: PGP signature