[lkml]   [2007]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Hibernation considerations
    On Monday, 16 July 2007 00:42, wrote:
    > On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:
    > > On Sunday, 15 July 2007 22:13, wrote:
    > >> On Sun, 15 Jul 2007, 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.
    > >>
    > >> AFAIK this is only the case with ext3, all other filesystems could be
    > >> accessed read-only safely
    > >>
    > >> this is arguably a bug with ext3 (and has been discussed as such), but
    > >> right now the ext3 team has decided not to change this bahavior so
    > >> hibernate needs to work around it. but don't mistake a work-around for a
    > >> single (admittedly very popular) filesystem with a hard and fast
    > >> directive.
    > >>
    > >>> (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.
    > >>
    > >> true, in fact, given that many distros and live-CD's autodetect swap
    > >> partitions and consider them fair game, I would argue that the best thing
    > >> to do would be to have the main system free up it's swap partitions before
    > >> going into hibernation.
    > >>
    > >> however, this could be a decision of the particular hibernate routines.
    > >>
    > >> for the kexec approach the mapping of what swap pages are in use is one
    > >> more chunk of data that needs to be assembled and made available through a
    > >> defined interface.
    > >>
    > >>> (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.
    > >>
    > >> it may make sense for this to be split into hard and soft limits.
    > >>
    > >> if you try to save more then the storage space can hold you cannot
    > >> continue, but if you are just a little over the arbatrary size limit that
    > >> was set to make things fast you are better off saving things as-is then
    > >> punting, going back to the system, trying to free more ram, and trying a
    > >> hibernate again.
    > >>
    > >> with the kexec approach the enforcment of these limits is also split into
    > >> two sections.
    > >>
    > >> when the hibernate command is given in the main kernel, it's userspace
    > >> needs to follow some policy to decide how much (if any) memory to free.
    > >
    > > How are you going to achieve this without (a) having hibernation-aware
    > > user space or (b) the freezer?
    > the hibernate command is a userspace command, but the fact that other
    > things in userspace are running at the same time is exactly why this is
    > only an estimate and best-effort as I said in the paragraph below.
    > >> but since the kexec command and the preporation of the devices can change
    > >> the memory, the estimates done by the first kernel's userspace are just
    > >> that, estimates.
    > >>
    > >>> (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.).
    > >>
    > >> for a pure hibernate mode, you will be powering off the box after saving
    > >> the suspend image. why are there any special ACPI modes involved?
    > >
    > > Because, for example, on my machine the status of power supply (present
    > > vs not present) is not updated correctly after the restore if ACPI callbacks
    > > aren't used during the hibernation. That's just experience and it's in line
    > > with the ACPI spec.
    > so if a machine is actually powered off the /dev/suspend process won't
    > work?

    No, it sort of works as usual, but after the restore the platform is not in the
    correct state.

    > remember that the system may run a different OS between the hibernate and
    > the resume, makeing any assumptions about what state the hardware is in
    > when you start the resume is a problem.

    True, that's problematic.


    "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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-07-16 01:17    [W:0.033 / U:7.424 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site