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