Date:	Mon, 27 Aug 2007 10:30:27 +0530
From:	Vivek Goyal <vgoyal@...ibm.com>
To:	"Huang, Ying" <ying.huang@...el.com>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Pavel Machek <pavel@....cz>, nigel@...el.suspend2.net,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jeremy Maitin-Shepard <jbms@....edu>,
	Alan Stern <stern@...land.harvard.edu>,
	linux-pm@...ts.linux-foundation.org,
	Kexec Mailing List <kexec@...ts.infradead.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH 0/2 -mm] kexec based hibernation

On Mon, Aug 27, 2007 at 09:14:05AM +0800, Huang, Ying wrote:
> Kexec base hibernation has some potential advantages over uswsusp and
> TuxOnIce (suspend2). Some most obvious advantages are:
> 
> 1. The hibernation image size can exceed half of memory size easily.
> 
> 2. The hibernation image can be written to and read from almost
>    anywhere, such as USB disk, NFS.
> 
> 3. It is possible to eliminate freezer from kexec based hibernation
>    implementation.
> 
> 4. Based on kexec/kdump implementation, the kernel code needed is
>    less.
> 
> 
> This patch set implements a prototype of kexec based hibernation. The
> kernel functionalities added are as follow:
> 
> 1. Jumping from kexeced kernel back to original kernel. This is used
>    by hibernation to save/load necessary state in original kernel and
>    jumping back to original kernel after restore the memory of
>    original kernel.
> 
> 2. Add writing support to /dev/oldmem. This is used by hibernation to
>    restore the memory of original kernel.
> 
> 
> The hibernation process with the patch set is as follow:
> 
> 1. Boot a kernel A
> 
> 2. Work under kernel A
> 
> 3. Kexec another kernel B (crash dump enabled) in kernel A.
> 
> 4. Save the memory image of kernel A through crash dump (such as "cp
>    /proc/vmcore ~"). Save the "jump buffer pfn".
> 
> 5. Shutdown or reboot
> 
> 
> The restore process with the patch set is as follow:
> 
> 1. Boot a kernel C
> 
> 2. Kexec another kernel D (crash dump enabled) in kernel C. The memory
>    area used by kernel D must be a subset of memory area used by
>    kernel B.
> 

If one compiles the kernel C to boot from reserved memory area (subset
of memory area used by kernel B), then I can skip the step of kexecing
from C to D? (COFIG_PHYSICAL_START)

Alternatively, can we give hint to kernel C to run from a specified address
at run time with the help of command line parameters. What I mean boot-loader
can load the kernel at any address, but kernel will move itself to run
from a different location depending on command line parameter.  For example,
let say kernel_run_addr = 0x1000000. This parameter will tell the kernel
to move itself to 16MB address and run from there. I think it can be made
to work with little work in existing setup of relocatable kernel.

Kernel run address can be put by some user space script which will save
the hibernated image of original kernel. So after saving the /proc/vmcore,
script can modify the boot loader config file to append the right
command line to the kernel (kernel_run_addr).

After hibernation, user will shutdown/reboot. Next time the kernel boots
it will load at 16MB addr (because of kernel_run_addr) and then it can
restore the previously saved image.

We shall have to get rid of (kernel_run_addr) parameter from command
line while resuming. One can restore the image (krestore) and then edit
the boot loader config file to get rid of command line param, kernel_run_addr.

In this scheme, with the help of relocatable kernel, we can use a single
kernel for everything. (A, B, C, D). We will also avoid additional kexec
from kernel C to kernel D.

I think in the long run we shall have to work out so that a user does
not have to maintain multiple kernels. 

Does this make sense?

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

Powered by blists - more mailing lists