[lkml]   [2007]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation
On Thursday, 12 July 2007 02:22, Andrew Morton wrote:
> On Wed, 11 Jul 2007 15:30:31 +0000
> "Huang, Ying" <> wrote:
> > Kexec base hibernation has some potential advantages over uswsusp and
> > suspend2. Some most obvious advantages are:
> >
> > 1. The hibernation image size can exceed half of memory size easily.
> > 2. The hibernation image can be written to and read from almost
> > anywhere, such as USB disk, NFS.
> >
> > This patch implements the functionality of "jumping from kexeced
> > kernel to original kernel". That is, the following sequence is
> > possible:
> >
> > 1. Boot a kernel A
> > 2. Work under kernel A
> > 3. Kexec another kernel B in kernel A
> > 4. Work under kernel B
> > 5. Jump from kernel B to kernel A
> > 6. Continue work under kernel A
> >
> > This is the first step to implement kexec based hibernation. If the
> > memory image of kernel A is written to or read from a permanent media
> > in step 4, a preliminary version of kexec based hibernation can be
> > implemented.
> >
> > The kernel B is run as a crashdump kernel in reserved memory
> > region. This is the biggest constrains of the patch. It is planed to
> > be eliminated in the next version. That is, instead of reserving memory
> > region previously, the needed memory region is backuped before kexec
> > and restored after jumping back.
> >
> > Another constrains of the patch is that the CONFIG_ACPI must be turned
> > off to make kexec jump work. Because ACPI will put devices into low
> > power state, the kexeced kernel can not be booted properly under
> > it. This constrains can be eliminated by separating the suspend method
> > and hibernation method of the devices as proposed earlier in the LKML.
> >
> > The kexec jump is implemented in the framework of software suspend. In
> > fact, the kexec based hibernation can be seen as just implementing the
> > image writing and reading method of software suspend with a kexeced
> > Linux kernel.
> >
> > Now, only the i386 architecture is supported. The patch is based on
> > Linux kernel 2.6.22, and has been tested on my IBM T42.
> This sounds awesome. Am I correct in expecting that ultimately the
> existing hibernation implementation just goes away and we reuse (and hence
> strengthen) the existing kexec (and kdump?) infrastructure?

Well, I haven't had the time to look at it more closely, but I'd assume that if
we can reuse the kexec infrastructure for hibernation, then yes, the existing
implementation will go away.

> And that we get hibernation support almost for free on all kexec (and
> relocatable-kernel?) capable architectures?

We should be able to, in theory.

> And that all the management of hibernation and resume happens in userspace?

I'm not sure what you mean here.

The image saving/loading certainly can be done in the user space.

> I didn't understand the ACPI problem. Does this mean that CONFIG_ACPI must
> be disabled in the to-be-hibernated kernel, or in the little transient
> kexec kernel?

I think that this mechanism requires that devices be not suspended (ie. in low
power states).


"Premature optimization is the root of all evil." - Donald Knuth
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-07-12 14:33    [W:0.256 / U:2.976 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site