public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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 --]

  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