Nick Piggin wrote:
Jeremy Maitin-Shepard wrote:
Nick Piggin <[email protected]> writes:
Yes, I have a rough idea about how page reclaim works. But I just
mean it would not be trivial to load the new kernel into physically
discontiguous memory. Possible of course, but I don't think kexec or
the setup code could quite cope ATM.
It would indeed be a pain for the new kernel to be loaded and have to
use discontiguous memory. The trick is, though, that this is not
necessary. Immediately before jumping to the new kernel, the first X
bytes (where X is the amount of memory the new kernel will get,
typically 16MB or 64MB) of physical memory are backed up into the
arbitrary discontiguous pages that are made available. This will not
take very long, because copying even 64MB of memory is extremely fast.
Then the new kernel is free to use the first X bytes of contiguous
physical memory. Problem solved.
Ah, that sounds like it would be the right way to go. Good thinking.
Hmm, considering it is not a crash situation, it might even be
better again to simply reuse the exising kernel text and kernel
page table and memory map information if possible. That would
probably only require a meg or two to reinit drivers, load a
suspend-to-disk-init, and do the IO.
OTOH it would likely be more complex than just freeing up a bit
of memory and relocating it.
--
SUSE Labs, Novell Inc.
-
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]