On Saturday, 14 July 2007 09:51, [email protected] 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
