Re: [linux-pm] Re: Hibernation considerations

From: david
Date: Sat Jul 21 2007 - 22:34:19 EST


On Sun, 22 Jul 2007, Huang, Ying wrote:

On Fri, 2007-07-20 at 08:48 -0700, david@xxxxxxx wrote:
Backuping target memory before kexec and restoring it after kexec is
planed feature for kexec jump. But I will work on image writing/reading
first.

if we can get a list of what memory is safe to backup/restore then the
reading/writing of the image should be able to be done in userspace.

The backup/restore here has nothing to do with the read/write of the
image. It means instead of preserving memory for a new kernel like that
of crash-dump, the memory for a new kernel is backupped before kexec and
restored after kexec by the kexec kernel.

Ok, I see the miscommunication here. you are talking about freeing up memory for the second kernel instead of reserving it from boot time.

I'm talking about getting the second kernel a list of what memory pages it should write to the image

if we can get the info for the list I'm looking for we should be able to demonstrate the kexec based hibernate.

the change you are talking about in an enhancment that is useful after that point to save some memory.

If the "scatter copy" is replaced by "scatter swap", we need not the
inverse list, and the state of kexeced kernel can be backuped too. There
are "scatter copy" support in normal kexec implementation in
"relocate_kernel".

what do you mean by "scatter swap"

copy: dest=src
swap: tmp=dest; dest=src; src=tmp

If memory is swapped, no information is lost, both that of kexec kernel
and kexeced kernel.

I'm missing why you need to preserve this memory

if you are talking about memory that will be used by the second kernel when you kexec to it then you don't need to preserve it (since it will be overwritten by the second kernel). if you aren't talking about memory that will be used by the second kernel why do you need to move it?

David Lang
-
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/