"Rafael J. Wysocki" <rjw@xxxxxxx> 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. [snip] -- Jeremy Maitin-Shepard _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
