Re: Hibernation Redesign

[Jeremy Maitin-Shepard]

Jeremy Fitzhardinge <jeremy@xxxxxxxx> writes:

> Jeremy Maitin-Shepard wrote:
>> I don't know a whole lot about xen, but it seems that one issue with
>> this approach is that it requires you run your system under a hypervisor
>> at all times, which may introduce some overhead.
>> 

> No, I don't think that's what Al is proposing.  The kernel-internal interfaces
> we've put in place to make Xen work could be reused to do some of the things
> you're talking about.  In particular, a kernel running under Xen has to be able
> to deal with non-contiguous physical pages, and reusing the same pagetable hooks
> would allow a kexeced kernel to run happily out of any random assortment of
> pages you manage to allocate for it.

I suppose that would be an interesting thing to look into.  Another
possible approach for having the kernel run in non-contiguous memory is
to specify a memmap exactly to the kernel on the command-line, as I
believe is done for the crashdump kernels currently.  It would, of
course, require an extremely long and complicated memmap specification
in general.  I recall reading, though, that even with the relocatable
kernel support, there are still significant alignment requirements for
loading the kernel.  In particular, I seem to recall that it is
necessary to load an x86 kernel at maybe a 16MB boundary, and on other
platforms the alignment requirements may be even more restrictive.  In
addition, I recall that the Linux boot procedure on x86 and on some
other platforms necessarily uses certain low-address memory, like the
first 640K, which must be backed up regardless.

For these reasons, it seems that it would be easiest to simply backup
the first e.g. 16 or 64 MB of memory, and not have to worry about
loading the kernel at a non-standard address and specifying a
complicated exact memmap.  Someone might prove me wrong, though.

-- 
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/