On Sat, 14 Jul 2007, Rafael J. Wysocki wrote:
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.
but per stable-abi-nonsense the internal structure of the kernel's pages
data isn't an abi. so instead of figuring this out by pokeing around in
the memory of the old kernel and deciding what should be saved and what
shouldn't, the old kernel (which understands the memory structure) should
create a simple map of what should be backed up (either a bitmap or an
extent-style map, depending on how many holes there are expected to be)
and then provide that map to the new kernel. the new kernel (or more
precisely it's userspace) reads the pages it's told to read and writes
them somewhere.
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 .
I'll look through this file, but the format of this is an abi/api to the
userspace and should be documented outside of the code.
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]
