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

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Saturday, 14 July 2007 23:13, david@lang.hm wrote:
> On Sat, 14 Jul 2007, Rafael J. Wysocki wrote:
> 
> > On Saturday, 14 July 2007 22:34, david@lang.hm wrote:
> >> in the past, Rafael J. Wysocki wrote:
> >>
> >>> BTW, please read this message and tell me what you think:
> >>>
> >>> http://lkml.org/lkml/2007/7/13/265
> >>>
> >>> Greetings,
> >>> Rafael
> >>>
> >>>
> >>>
> >>
> >> since I've deleted this message here's the relavent portion of it
> >>
> >>> Okay, I have thought it through and I think that, as an initial step, we
> >>> can do something like this:
> >>>
> >>> - preload the image-saving kernel before hibernation
> >>> - in the hibernation code path replace device_suspend() with the shutting
> >>> down of all devices without unregistering them (not very nice, but should be
> >>> sufficient for a while)
> >>> - when we've called device_power_down() and save_processor_state(), jump
> >>> to the image-saving kernel and let it run
> >>> - make the image-saving kernel set up everything, save the image without
> >>>  starting any user space (we may use the existing image-saving code for
> >>> this purpose, with some modifications) and power off the system (or make it
> >>> enter S4)
> >>> - use the existing restoration code to load the image and jump to the
> >>>  hibernated kernel
> >>> - in the restore code patch replace device_resume() with the reprobing of
> >>> all devices.
> >>>
> >>> Comments?
> >>
> >> I think this is far more complicated then it needs to be.
> >>
> >> it sounds like it should be possible to do the following
> >>
> >> 1. figure out what pages should be backed up (creating a data structure to
> >> hold them)
> >
> > That should be done after step 2, because the memory contents can change
> > in this step.
> 
> no, this needs to be done by the main kernel, becouse only it knows how to 
> find this info. the kernel that you kexec into could be very different 
> (including different versions) and the ways to identify this data is not 
> part of any existing API

If the memory contents changes in step 2, then the information collected by
the main kernel will be inaccurate.

> >> 2. kexec into the hibernate kernel (this step handles all device
> >> transitions today)
> >>
> >> 3. have the hibernate userspace find the data structures created in step
> >> #1
> >>
> >> 4. have the hibernate userspace write the pages somewhere in the suspend
> >> format.
> >
> > You don't need to run any hibernate userspace to carry out steps 3 and 4.
> 
> you should though.
> 
> by doing this write in usespace you can add in all the eye-candy (aka 
> progress bars), network I/O, etc that you want since it doesn't affect 
> things
> 
> trying to do this in the kernel makes the kernel have to know/decide too 
> much policy (and many things that people want to do are things that do not 
> belong in the kernel in the first place)

Please don't tell me.  I've written uswsusp on the basis of these arguments,
but I don't cosider it as an overwhelming success ...

> >> 5. have the hibernate kernel power down the box.
> >>
> >> the only things here that sounds like they're not available in stock
> >> kernels are steps #1 and #3.
> >
> > Correct, up to the first remark above.
> >
> >> now this won't do the fancier suspend-to-ram-and-disk and it won't let you
> >> go back from the hibernate kernel to the main kernel, but it should be
> >> enough to let you do the suspend safely and reliably.
> >>
> >> for the restore, as I understand it the process is
> >>
> >> 1. boot a kernel, any working kernel.
> >>
> >> 2. read the suspend formatted data from wherever it was saved and feed it
> >> to /dev/suspend
> >
> > Yes, something like this, but you really should pay more attention to devices.
> >
> > There are things that you shouldn't do to them (like unregistering), because
> > some processes may be using them while we're trying to hibernate (for now
> > we have the freezer, but I though you'd like to do all that to eliminate it).
> >
> > Generally, you need to ensure that the devices are handled in consistent ways
> > by both the hibernated and image-saving kernels and that's a big piece of the
> > jigsaw that's missing now.
> 
> the kexec process should handle the device state for the transition from 
> one kernel to another (it has to do this now, this isn't a new 
> requirement), so this should solve the problem during the hibernate stage.

Well, I don't think so.

> during the wakeup stage, I thought you said that al that was needed was to 
> feed the suspend image to /dev/suspend and the kernel in the suspend image 
> would re-probe, or otherwise re-initialize all the devices it needs. am I 
> misunderstanding this?

Perhaps.  Currently, the hibernated kernel will run device_resume() after
the restore, which is not exactly compatible with what kexec does.

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/