From: Nigel Cunningham <nigel@nigel.suspend2.net>
To: Al Boldi <a1426z@gawab.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Mark Lord <lkml@rtr.ca>,
Jeremy Maitin-Shepard <jbms@cmu.edu>,
Miklos Szeredi <miklos@szeredi.hu>,
jeremy@goop.org, pavel@ucw.cz, nickpiggin@yahoo.com.au,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org
Subject: Re: Hibernation Redesign
Date: Thu, 12 Jul 2007 09:31:43 +1000 [thread overview]
Message-ID: <200707120931.44456.nigel@nigel.suspend2.net> (raw)
In-Reply-To: <200707120212.24072.a1426z@gawab.com>
[-- Attachment #1: Type: text/plain, Size: 3983 bytes --]
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 #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-07-11 23:32 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-08 14:37 Hibernation Redesign (was: malicious filesystems (was Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM) Al Boldi
2007-07-09 4:11 ` Hibernation Redesign Jeremy Maitin-Shepard
2007-07-09 4:29 ` Nick Piggin
2007-07-09 4:36 ` Jeremy Maitin-Shepard
2007-07-09 4:45 ` Nick Piggin
2007-07-09 4:54 ` Jeremy Maitin-Shepard
2007-07-09 4:58 ` Nick Piggin
2007-07-09 5:33 ` Nick Piggin
2007-07-09 6:22 ` Jeremy Fitzhardinge
2007-07-09 13:45 ` Pavel Machek
2007-07-09 14:02 ` Oliver Neukum
2007-07-09 14:26 ` Jeremy Maitin-Shepard
2007-07-09 15:09 ` Oliver Neukum
2007-07-09 15:27 ` Jeremy Maitin-Shepard
2007-07-09 4:39 ` Nick Piggin
2007-07-09 13:52 ` Pavel Machek
2007-07-09 15:30 ` Al Boldi
2007-07-10 1:29 ` Nick Piggin
2007-07-10 2:28 ` Jeremy Maitin-Shepard
2007-07-10 14:57 ` Jeremy Fitzhardinge
2007-07-10 17:25 ` Jeremy Maitin-Shepard
2007-07-10 22:59 ` Jeremy Fitzhardinge
2007-07-11 4:11 ` Al Boldi
2007-07-11 10:27 ` Rafael J. Wysocki
2007-07-11 10:42 ` Miklos Szeredi
2007-07-11 11:04 ` Rafael J. Wysocki
2007-07-11 11:11 ` Miklos Szeredi
2007-07-11 11:50 ` Rafael J. Wysocki
2007-07-11 11:54 ` Miklos Szeredi
2007-07-11 12:00 ` Nigel Cunningham
2007-07-11 12:09 ` Miklos Szeredi
2007-07-11 12:17 ` Nigel Cunningham
2007-07-11 12:27 ` Rafael J. Wysocki
2007-07-11 12:29 ` Miklos Szeredi
2007-07-11 21:04 ` Rafael J. Wysocki
2007-07-12 9:15 ` Pavel Machek
2007-07-12 22:13 ` Miklos Szeredi
2007-07-11 12:19 ` Rafael J. Wysocki
2007-07-11 12:49 ` Nigel Cunningham
2007-07-11 21:06 ` Rafael J. Wysocki
2007-07-11 12:11 ` Nigel Cunningham
2007-07-11 12:24 ` Miklos Szeredi
2007-07-11 12:46 ` Nigel Cunningham
2007-07-11 12:55 ` Miklos Szeredi
2007-07-11 13:16 ` Jeremy Maitin-Shepard
2007-07-11 20:48 ` Mark Lord
2007-07-11 21:14 ` Rafael J. Wysocki
2007-07-11 22:17 ` Al Boldi
2007-07-11 22:34 ` Rafael J. Wysocki
2007-07-11 23:12 ` Al Boldi
2007-07-11 23:31 ` Nigel Cunningham [this message]
2007-07-12 3:11 ` Al Boldi
2007-07-12 13:20 ` Rafael J. Wysocki
2007-07-16 6:04 ` Nick Piggin
2007-07-12 20:29 ` Jeremy Maitin-Shepard
2007-07-11 23:46 ` Nigel Cunningham
2007-07-11 17:55 ` david
2007-07-11 22:54 ` Nigel Cunningham
2007-07-10 17:45 ` Al Boldi
2007-07-10 18:20 ` Jeremy Maitin-Shepard
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=200707120931.44456.nigel@nigel.suspend2.net \
--to=nigel@nigel.suspend2.net \
--cc=a1426z@gawab.com \
--cc=akpm@linux-foundation.org \
--cc=jbms@cmu.edu \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@rtr.ca \
--cc=miklos@szeredi.hu \
--cc=nickpiggin@yahoo.com.au \
--cc=pavel@ucw.cz \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox