From: Jeremy Maitin-Shepard <jbms@cmu.edu>
To: linux-kernel@vger.kernel.org
Cc: Linus Torvalds <torvalds@osdl.org>,
       Nigel Cunningham <nigel@nigel.suspend2.net>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Pavel Machek <pavel@ucw.cz>
Cc: suspend2-devel@lists.suspend2.net
Subject: A kexec approach to hibernation
Date: Fri, 01 Jun 2007 16:39:51 -0400
Message-ID: <878xb3l888.fsf@jbms.ath.cx>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.990 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3739
Lines: 80

I figured I'd throw this idea out, since although it is not perfect, it
has the potential to elegantly solve a lot of issues with hibernate.

Just as kexec can now be used to write a crashdump after a kernel panic,
a fresh kexec-loaded kernel (loaded into unused memory) could be used to
write the hibernate image of the existing kernel to disk, and then power
off the system (or suspend to ram, or anything else).  This avoids the
need for the original kernel to jump through hoops to hibernate itself
in place.

A hibernate sequence would be approximately as follows:
 
 1. Free some memory if needed or desired, and disable the swap device
    if it is going to be used to write the hibernate image.

 2. Load the fresh kernel in a chunk of available (possibly
    pre-allocated) memory (there must also be enough available memory
    for this kernel to use).

 3. Disable interrupts and stop all devices.

 4. Jump to the new kernel, passing whatever state information will be
    needed by it to know how to write the image.

 5. The new kernel loads, and then either kernel space or user space
     writes the necessary data from the old kernel to disk.

 6. The new kernel either powers off or suspends to ram.  If it suspends
    to ram, then it would need to be able to jump back to the old kernel
    when it resumes from ram.

The advantages of this approach include:

 - having a completely functional system (with a completely functional
   userspace) from which the image is written, without having to worry
   about messing up the state that is being saved (hell, the user could
   even do it via an interactive shell on the new kernel);

 - no need to worry about trying to use drivers while some processes are
   frozen;

 - no need for complicated process freezing; the same logic that can be
   used for suspend to ram should be sufficient;

 - no need for an atomic copy of memory, or any other complicated memory
   copying; the memory of the old kernel, including the page cache, can
   be written directly;

 - instead of needing a significant amount of free memory to store the
   atomic copy, only a few megabytes would needed to load and run the
   new kernel.

It may or may not be necessary to require that the new kernel used to
write the image is the same as the existing kernel; it will likely be
useful to require that it is built from the same sources and with a
similar config.  It would likely be useful, however, to either compile
out or (e.g. via the kernel command-line) disable the initialization of
drivers that will not be needed to write the image, such as sound
drivers, cdrom drivers, filesystems, and network drivers (if the image
is not to be written via the network).

Of course, if special initialization was needed under the original
kernel to set up the devices that will be used to write the image, such
as device mapper setup, or network initialization, that will have to be
repeated under the new kernel as well.  This is the principal
disadvantage to this approach, but since it must be done during resume
from hibernation in any case, it doesn't seem like a very significant
disadvantage.  The other disadvantage is that there would be the
delay of loading the fresh kernel; this may, however, only take a second
or two, which is relatively insignificant compared to the time required
to actually write the image, and the delay could be reduced by stripping
out unnecessary drivers from the image-writing kernel.

-- 
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/