On Fri, 2007-09-21 at 12:25 +1000, Nigel Cunningham wrote: > Hi. > > On Friday 21 September 2007 12:18:57 Huang, Ying wrote: > > > That's not true. Kexec will itself be an implementation, otherwise you'd > end > > > up with people screaming about no hibernation support. And it won't result > in > > > the complete removal of the existing hibernation code from the kernel. At > the > > > very least, it's going to want the kernel being hibernated to have an > > > interface by which it can find out which pages need to be saved. I > wouldn't > > > > This has been done by kexec/kdump guys. There is a makedumpfile utility > > and vmcoreinfo kernel mechanism to implement this. We can just reuse the > > work of kexec/kdump. > > You've already said that you are currently saving all pages. How are you going > to avoid saving free pages if you don't get the information from the kernel > being saved? This will require more than just code reuse. I have not tried "makedumpfile". The "makedumpfile" avoids saving free pages through checking the "mem_map" of the original kernel. I think there is nothing prevent it been used for kexec based hibernation image writing. This is an example of duplicated effort between kexec/kdump and original hibernation implementation. Both kexec/kdump and hibernation need to save memory image without saving the free pages. This can be done once instead of twice. > > > be surprised if it also ends up with an interface in which the kernel > being > > > hibernated tells it what bdev/sectors in which to save the image as well > > > (otherwise you're going to need a dedicated, otherwise untouched partition > > > exclusively for the kexec'd kernel to use), or what network settings to > use > > > if it wants to try to save the image to a network storage device. On top > of > > > > These can be done in user space. The image writing will be done in user > > space for kexec base hibernation. > > That only complicates things more. Now you need to get the information on > where to save the image from the kernel being saved, then transfer it to > userspace after switching to the kexec kernel. That's more kernel code, not > less. This is fairly simple in fact. For example, you can specify the bdev/sectors in kernel command line when do kexec load "kexec -l <...> --append='...'", then the image writing system can get it through "cat /proc/cmdline". > > > that, there are all the issues related to device reinitialisation and so > on, > > > > Yes. Device reinitialisation is needed. But all in all, kexec based > > hibernation can be much simpler on the kernel side. > > Sorry, but I'm yet to be convinced. I'm not unwilling, I'm just not there yet. > > > > and it looks like there's greatly increased pain for users wanting to > > > configure this new implementation. Kexec is by no means proven to be the > > > panacea for all the issues. > > > > Configuration is a problem, we will work on it. > > > > But, because it is based on kexec/kdump instead of starting from > > scratch, the duplicated part between hibernation and kexec/kdump can be > > eliminated. > Best Regards, Huang Ying _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
