[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.029 / U:43.160 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site