Re: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Saturday, 14 July 2007 09:51, david@lang.hm 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.

Yes.

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:

http://lkml.org/lkml/2007/7/13/265

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth