Re: Hibernation considerations

Nigel Cunningham
2007-07-15T12:51:35Z

[-- Attachment #1.1: Type: text/plain, Size: 6039 bytes --]

Hi.

On Sunday 15 July 2007 22:33:32 Rafael J. Wysocki wrote:
> Hi,
>
> Since many alternative approaches to hibernation are now being considered
and
> discussed, I thought it might be a good idea to list some things that in my
not
> so humble opinion should be taken care of by any hibernation framework.
They
> are listed below, not in any particular order, because I think they all are
> important. Still, I might have forgotten something, so everyone with
> experience in implementing hibernation, especially Pavel and Nigel, please
> check if the list is complete.
>
> (1) Filesystems mounted before the hibernation are untouchable
>
> When there's a memory snapshot, either in the form of a hibernation
image,
> or in the form of the "old" kernel and processes available to the "new"
> kexeced kernel responsible for saving their memory, the filesystems
mounted
> before the hibernation should not be accessed, even for reading, because
> that would cause their on-disk state to be inconsistent with the
snapshot
> and might lead to a filesystem corruption.
>
> (2) Swap space in use before the hibernation must be handled with care
>
> If swap space is used for saving the memory snapshot, the
snapshot-saving
> application (or kernel) must be careful enough not to overwrite swap
pages
> that contain valid memory contents stored in there before the
hibernation.
>
> (3) There are memory regions that must not be saved or restored
>
> Some memory regions contain data that shouldn't be overwritten during
the
> restore, because that might lead to the system not working correctly
> afterwards. Also, on some systems there are valid 'struct pages'
> structures that in fact corresond to memory holes and we should not
attempt
> to save those pages.
>
> (4) The user should be able to limit the size of a hibernation image
>
> There are a couple of reasons of that. For example, the storage space
> used for saving the image may be smaller than the entire RAM or the user
> may want the image to be saved quickier.
>
> (5) Hibernation should be transparent from the applications' point of view
>
> Generally, applications should not notice that hibernation took place.
> [Note that I don't regard all processes as applications and I think that
> there may be processes which need to handle the hibernation in a special
> way.] Ideally, for example, if some audio is being played when a
> hibernation starts, the audio player should be able to continue playing
the
> same audio after the restore from the point in which it has been
> interrupted by the hibernation. Also, the CPU affinities and similar
> settings requested by the applications before a hibernation should be
> binding after the restore.
>
> (6) State of devices from before hibernation should be restored, if possible
>
> If possible, during a restore devices should be brought back to the same
> state in which they were before the corresponding hibernation. Of
course
> in some situations it might be impossible to do that (eg. the user
> connected the hibernated system to a different IP subnet and then
> restored), but as a general rule, we should do our best to restore the
> state of devices, which is directly related to point (5) above.
>
> (7) On ACPI systems special platform-related actions have to be carried out
at
> the right points, so that the platform works correctly after the restore
>
> The ACPI specification requires us to invoke some global ACPI methods
> during the hibernation and during the restore. Moreover, the ordering
of
> code related to these ACPI methods may not be arbitrary (eg. some of
> them have to be executed after devices are put into low power states
etc.).
>
> (8) Hibernation and restore should not be too slow
>
> In my opinion, if more than one minute is needed to hibernate the system
> with the help of certain hibernation framework, then this framework is
not
> very useful in practice. It might be useful to perform some special
tasks
> (eg. moving a server to another place without taking it down), but it is
> not very useful, for example, to notebook users.
>
> (9) Hibernation framework should not be too difficult to set up
>
> It follows from my experience that if the users are required to do too
much
> work to set up a hibernation framework, they will not use it as long as
> there are simpler alternatives (some of them will not use hibernation at
> all if it's too difficult to get to work). On the other hand, if the
users
> are provided with a working hibernation framework by their distribution
> and they find it useful, they are not likely to use kernel.org kernels
if
> t's too difficult to replace the distribution kernel with a generic one
due
> to the hibernation framework's requirements.
>
> All of the existing hibernation frameworks have been written with the above
> points in mind and that's why they are what they are. In particular, the
> existence of the tasks freezer, hated by some people to the point of
insanity,
> follows directly from points (1), (4) and (5).
>
> In my opinion any hibernation framework that doesn't take the above
> requirements into account in any way will be a failure. Moreover, the
existing
> frameworks fail to follow some of them too, so I consider all of these
> frameworks as a work in progress. For this reason, I will much more
appreciate
> ideas allowing us to improve the existing frameworks in a more or less
> evolutionary way, then attempts to replace them all with something entirely
> new.

Sounds good to me. Nothing extra occurs immediately.

Regards,

Nigel
--
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]