[lkml]   [2007]   [Jul]   [14]   [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 Saturday, 14 July 2007 09:51, wrote:
    > On Fri, 13 Jul 2007, Rafael J. Wysocki wrote:
    > >> Ok, now we need a data channel from the old kernel to the hibernate
    > >> kernel, to the restore kernel. and the messier the memory layout the
    > >> larger this data channel needs to be (hmm, what's the status on the memory
    > >> defrag patches being proposed?) if this list can be made small enough it
    > >> would work to just have the old kernel put the data in a known location in
    > >> ram, and let the other two parts find it (in ram for the hibernate kernel,
    > >> in the hibernate image for the wakeup kernel).
    > >
    > > I think the hibernation kernel should mmap() the "old" kernel's (and it's
    > > processes') memory available for saving, so that the image-saving process
    > > can read its contents from the original locations.
    > but I'll bet that not all kernels keep the info in the same place (and
    > probably not even in the same format). I'm suggesting that a standard be
    > defined for the format of the data and the location of a pointer to it
    > that will be maintained across kernel versions.


    The image-saving kernel needs to have access to the hibernated kernel's
    pages data, plus some additional information that should be passed in a
    standard format.

    > >> how do the existing hibernate processes store this?
    > >
    > > There are two approaches. In the first of them (used in the mainline) we just
    > > create copies of all pages eligible for saving (hence we can't create images
    > > larger than 50% of RAM) atomically and then we save the contents of these
    > > copies (either directly from the kernel or through a user space process). This
    > > way we don't need to worry that they may be modified before we can save
    > > them.
    > >
    > > The other approach is the Nigel's one, in which all LRU pages are first saved
    > > and then used as additional storage for copying the rest of memory contents.
    > > This has a drawback that we are not 100% sure if the LRU won't be modified
    > > after we've used them to store the copies of the other pages.
    > and since both current approaches use the same kernel for everything the
    > issues I'm thinking of simply don't apply.
    > >> since people are complaining about the amount of ram that a kexec kernel
    > >> would take up I'm assuiming it's somethingmore complex then just a bitmap
    > >> of all possible pages.
    > >
    > > No, it's just bitmaps, AFAICS, and the complaints are a bit overstated, IMO. ;-)
    > 1 bit for each 4k means 1m bits for 4g of ram, or 128k of bitmaps, growing
    > up to 1m of ram used for 32G of ram in the system. I guess this isn't bad
    > as long as it doesn't need to be contiguous for the new kernel to access
    > it.
    > ok, that makes it a pretty trivial thing to work with. I just need to
    > learn how to find the bitmaps.

    They are created on the fly before the hibernation. The format is described in
    kernel/power/snapshot.c .

    > >> most of the conversation so far has been around the process of makeing the
    > >> snapshot and storing it. what are the processes and tools available to
    > >> restore images?
    > >
    > > We have quite an efficient restoration code in the kernel right now. It's
    > > able to upload big images (something like total RAM minus the size of the
    > > boot kernel, initrd and, optionally, the resume application), which is much
    > > more than we're able to save. :-)
    > >
    > > It can work with images uploaded via /dev/snapshot from the user space
    > > (specific image format is required, but that can be changed easily).
    > Ok, so it sounds as if the restore is basicly a solved problem, great!
    > so now I want to do a but-ugly hibernate configuration.
    > while I haven't done it yet I am very confident that I can enable kexec
    > and create a kernel and filesystem to boot into. I can then use perl to
    > get the bitmaps out of kmem (once I learn how to find them), and then can
    > read from kmem to a file to save the 4k chunks that I need to a file.
    > it'll be ugly and use lots of partitions, but it should end up being solid
    > from what I am understanding.
    > where can I learn how to find the bitmaps and what format things need to
    > be in to feed into /dev/snapshot?

    Well, see above.

    BTW, please read this message and tell me what you think:


    "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-14 21:55    [W:0.026 / U:7.308 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site