On Fri, 20 Jul 2007, Milton Miller wrote:
On Jul 19, 2007, at 12:31 PM, [email protected] wrote:
On Thu, 19 Jul 2007, Milton Miller wrote:
>
> This means that the first kernel will need to know why it got resumed.
> Was the system powered off, and this is the resume from the user? Or
> was it restarted because the image has been saved, and its now time to
> actually suspend until woken up? If you look at it, this is the same
> interface we have with the magic arch_suspend hook -- did we just
> suspend and its time to write the image, or did we just resume and its
> time to wake everything up.
>
> I think this can be easily solved by giving the image saving kernel two
> resume points: one for the image has been written, and one for we
> rebooted and have restored the image. I'm not familiar with ACPI.
> Perhaps we need a third to differentiate we read the image from S4
> instead of from S5, but that information must be available to the OS
> because it needs that to know if it should resume from hibernate.
are we sure that there are only 2-3 possible actions? or should this be
made into a simple jump table so that it's extendable?
At 2 I don't think we need a jump table. Even if we had a table, we have to
identify what each entry means. If we start getting more then we can change
from command line to table.
Ok, I was just looking to future-proof things so that these features can
work on older kernels (as opposed to having two interfaces and when we
switch from one to the next kernels older then that can't be used)
remember that the save and restore kernel can access the memory of the
suspending kernel, so as long as the data is in a known format and there
is a pointer to the data in a known location, the save and restore kernel
can retreive the data from memory, there's no need to involve media.
I agree that the the save kernel can read the list from the being-saved
kernel.
However, when restoring, the being-saved (being-restored) kernel is not
accessable, so the save list has to be stored as part of the image.
at that point it's less a save list then just the record of where the
memory pages belong. you can use the same list, but you can store it along
with the memory image. there's still no need for the suspending kernel to
save it to permanent media.
> Simplifying kjump: the proposal for v3.
>
> The current code is trying to use crash dump area as a safe, reserved
> area to run the second kernel. However, that means that the kernel has
> to be linked specially to run in the reserved area. I think we need to
> finish separating kexec_jump from the other code paths.
on x86 at least it's possible to compile a relocateable kernel, so it
doesn't need to be compiled specificly for a particular reserved area.
This would allow you to use the same kernel build as the suspending kernel
if you wanted to (I think that the config of the save and restore kernel
is going to be trivial enough to consider auto-configuring and building a
specific kernel for each box a real possibility)
Yes, one *can* build x86 relocatable. But there are funny restrictions like
it has to be a bzImage or be loaded by kexec or something. And not all
architectures have relocatable support. I think making the lists for the
exsiting code to swap memory will not be that difficult and it will make the
solution have less restrictions. Maybe I should shut up and write some code
this weekend.
Actually, I think we can have the dedicated area as an option. If you
suspend frequently keep a relocated kernel booted. If you need more ram or
suspend infrequently allocate the pages on the fly.
for the proof of concept that we are trying for now there's no need to
implement the capability to free memory to make room for the kexec kernel.
after we show that this can work that can be added.
> As a first stage of suspend and resume, we can save to dedicated
> partitions all memory (as supplied to crash_dump) that is not marked
> nosave and not part of the save kernel's image. The fancy block lists
> and memory lists can be added later.
if the suspending kernel needs to tell the save and restore kernel what
memory is not marked nosave have it do so useing a memory list of some
kind. you need to setup a mechanism for communicating the data anyway,
setup a mechansim that's useable in the long term.
I'm saying we can have people start to test by the simple save all ram to
dedicated while we figure out what the long term list looks like.
the only problem with this is that Rafael is saying that if you try to
save all the ram you will fail (in some cases becouse you are trying to
save ram that doesn't exist). so at the very least we need to get a list
that tells us what _can_ be saved.
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]
