[lkml]   [2007]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Hibernation considerations

    On Sunday 15 July 2007 22:33:32 Rafael J. Wysocki wrote:
    > Hi,
    > Since many alternative approaches to hibernation are now being considered
    > discussed, I thought it might be a good idea to list some things that in my
    > so humble opinion should be taken care of by any hibernation framework.
    > 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
    > or in the form of the "old" kernel and processes available to the "new"
    > kexeced kernel responsible for saving their memory, the filesystems
    > before the hibernation should not be accessed, even for reading, because
    > that would cause their on-disk state to be inconsistent with the
    > 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
    > application (or kernel) must be careful enough not to overwrite swap
    > that contain valid memory contents stored in there before the
    > (3) There are memory regions that must not be saved or restored
    > Some memory regions contain data that shouldn't be overwritten during
    > 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
    > 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
    > 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
    > 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
    > 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
    > 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
    > (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
    > very useful in practice. It might be useful to perform some special
    > (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
    > 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
    > are provided with a working hibernation framework by their distribution
    > and they find it useful, they are not likely to use kernels
    > t's too difficult to replace the distribution kernel with a generic one
    > 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
    > 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
    > 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
    > 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.


    See for Howtos, FAQs, mailing
    lists, wiki and bugzilla info.
    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2007-07-15 23:53    [W:0.030 / U:38.564 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site