![]() | |||||||||||
Messages in this thread |
On Mon, 16 Jul 2007, Rafael J. Wysocki wrote: > On Sunday, 15 July 2007 22:13, david@lang.hm 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? 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. David Lang >> now, for suspend-to-ram you need to be aware of every possible power >> saving option you have and the cost of each of them, and here the ACPI >> modes are heavily used. >> >> I think this is mixing suspend and hibernate still. > > Yes, it is, but that's not we who's mixing. We just need to handle some > systems built with ACPI in mind. > > Greetings, > Rafael > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||
| Last update: 2007-07-16 00:51 [from the cache] ©2003-2008 | |||||||||||