lkml.org 
[lkml]   [2007]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
From
Date
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-09-21 04:47    [W:0.144 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site