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
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
