Re: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation

[Rafael J. Wysocki]

On Thursday, 12 July 2007 16:43, Huang, Ying wrote:
> On Wed, 2007-07-11 at 17:22 -0700, Andrew Morton wrote:
> > This sounds awesome.  Am I correct in expecting that ultimately the
> > existing hibernation implementation just goes away and we reuse (and hence
> > strengthen) the existing kexec (and kdump?) infrastructure?
> > And that we get hibernation support almost for free on all kexec (and
> > relocatable-kernel?) capable architectures?
> > And that all the management of hibernation and resume happens in userspace?
> 
> Yes. Ultimately, most of the hibernation code such as process freezer,
> memory shrinking, memory snapshot (atomic copy), image reading/writing
> can go away, because kexec based hibernation doesn't depend on them.
> Just the device/CPU state quiescent/save/restore is necessary to remain.
> And, the management of hibernation and resume will happen in userspace.
> 
> > 
> > I didn't understand the ACPI problem.  Does this mean that CONFIG_ACPI must
> > be disabled in the to-be-hibernated kernel, or in the little transient
> > kexec kernel?
> 
> Under current implementation of device state quiescent/save/restore, the
> CONFIG_ACPI must be turned off both in to-be-hibernated kernel and
> transient kexec kernel.
> 
> But the hibernation people are going to separate the device suspend from
> device hibernate. The device hibernate will put device in quiescent
> state but not in low power state. When this is done, it is not necessary
> to disable CONFIG_ACPI at all. It is just a workaround for current
> implementation that disabling CONFIG_ACPI.
> 
> > How close do you think all this is to being a viable thing?
> 
> The kexec jump is the first step, maybe the simplest step. There are
> many other issues to be resolved, at least the following ones.
> 
> 1. Separate device suspend from device hibernate.

Step 0, I'd say. :-)

> 2. Do not reserve memory for kexec kernel. That is, backup needed memory
> before kexec and restore them after kexec.

I don't think this is very important initially.

> 3. Support the in-place kexec? The relocatable kernel is not necessary
> if this can be implemented.
> 4. Image writing/reading. (Only user space application is needed).

And a kernel interface for that application.

> 5. A smooth resume process. Maybe it is not needed to kexec a new kernel
> for resume. For example, in the first stage of kernel boot, just first
> 16M (or a little more) RAM is used, if the resume image is found, the
> saved kernel image is resumed; if the resume image is not found, turn on
> the remaining RAM. This will depends on 3.

I think that this is the most difficult part of the whole thing.

> 6. Reduce the boot-up time of kexec kernel. Maybe the kexec kernel can
> be hibernate/resume by the normal kernel too. This way, a real
> kexec/boot-up is only needed for the first time.

I'm not sure what you mean.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth
-
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/