On Friday, 13 July 2007 17:12, Jeremy Maitin-Shepard wrote:
> "Rafael J. Wysocki" <[email protected]> writes:
>
> [snip]
>
> > Not necessarily. If we don't put devices into low power states before creating
> > the image, that should work just fine (quiesce devices, create the image or
> > kexec the new kernel, reprobe devices, save the image, suspend to RAM,
> > resume from RAM, continue - or restore from the image if power failed in the
> > meantime). Still, for this purpose, both kernels need to be able to handle the
> > same set of devices.
>
> I don't know much about the suspend to RAM, but it seems that it would
> indeed be necessary to have a device driver for a device in order to
> switch it from e.g. a quiesced state to a low power state. If, however,
> the original kernel already completely turned off the device, then it
> seems that the "save image" kernel shouldn't have to do anything to it
> in order to suspend to RAM. The drawback, though, is that since the old
> kernel would have no way (unless the user tells it) to know which
> devices should be left quiesced and which should be turned off, it would
> have to turn them all off, which would mean spinning up and down the
> disks.
>
> On the other hand, being able to build the "save image" kernel with only
> minimal hardware support could save a significant amount of the time
> required to boot it.
>
> [snip]
>
> > No, it can't. For example, it can't access filesystems mounted by the
> > hibernated kernel, or they may get corrupted after the restore (if they are
> > journaling, it can't even read from them).
>
> That is true, but this also holds for the current hibernate
> implementations.
>
> > Which reminds me of one more issue, which is that the image-saving kernel
> > won't be able to use these filesystems either, so its modules and user space
> > will have to be available from somewhere else (like a RAM disk or dedicated
> > partition). So things get ugly.
>
> This is not the issue that it appears to be, though. Under the current
> hibernate implementations, this very same userspace and set of modules
> must be available "somewhere else" (i.e. an initrd) because it is needed
> by the restore path. Note that under the kexec approach, save and
> restore become rather symmetric operations.
>
> > Apart from this, the new kernel's user space cannot blindly modify swap space
> > that might be in use by the hibernated kernel.
>
> But it seems easy enough to swapoff in order to completely free up the
> swap space. I suppose the disadvantage is that instead of failing
> cleanly if there is insufficient memory, the OOM killer will be invoked
> and cause all sorts of havoc. This suggests that it may indeed be
> important to support "cooperation" with the old kernel on saving the
> image sooner, rather than later.
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?
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
