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.
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.
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?
David Lang
-
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]
