[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
    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

    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-09-21 04:47    [W:0.026 / U:8.596 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site