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