On Tuesday, 17 July 2007 22:27, david@xxxxxxx wrote: > On Tue, 17 Jul 2007, Alan Stern wrote: > > > On Tue, 17 Jul 2007, Rafael J. Wysocki wrote: > > > >> I'm afraid of one thing, though. > >> > >> If we create a framework without ACPI (well, ACPI needs to be enabled in the > >> kernel anyway for other reasons, like the ability to suspend to RAM) and then > >> it turns out that we have to add some ACPI hooks to it, that might be difficult > >> to do cleanly. > >> > >> Thus, it seems reasonable to think of the ACPI handling in advance. > > > > Absolutely. This needs to be done in such a way that it will work: > > > > On platforms without ACPI; > > > > On platforms with ACPI where we do a non-ACPI type of shutdown > > to whatever extent it is possible (or perhaps an ACPI-aware > > shutdown rather than change to S4); > > > > On platforms with ACPI where we do an ACPI-aware transition > > to S4. > > > > Rafael, for those of us who aren't thoroughly familiar with all the ins > > and outs of the ACPI spec, could you please summarize a list of the > > ACPI calls needed in the second and third cases above? Indicate which > > ones need to be done from within the original kernel and which should > > be done from within a kexec'd hibernation kernel. > > > > there was just a link on slashdot toa primer on the subject of power > management > > http://www.techarp.com/showarticle.aspx?artno=420 > > > > > I'm still not entirely clear on how "suspend-to-both" ought to be > > handled. Presumably it will start off as a normal hibernation. But > > instead of shutting down, wouldn't the kexec'd kernel return to the > > original kernel? After all, the original kernel knows about all the > > devices and can put them into a low-power state, while the kexec'd > > kernel might not have sufficient information. > > this is what I'm thinking, but the issue here is that the original kernel > needs to go into suspend-to-ram mode instead of resuming operation. per > the e-mail I got from Ying last night this should not be hard to > implement. > > > But what about the freezer? The original reason for using kexec was to > > avoid the need for the freezer. With no freezer, while the original > > kernel is busy powering down its devices, user tasks will be free to > > carry out I/O -- which will make the memory snapshot inconsistent with > > the on-disk data structures. > > no, user tasks just don't get scheduled during shutdown. > > the big problem with the freezer isn't stopping anything from happening, > it's _selectivly_ stopping things. It's selectively stopping kernel threads, which is just about right. If you that _this_ is a main problem with the freezer, then think again. > with kexec you don't need to let any portion of the origional kernel or > userspace operate so you don't have a problem. In fact, the main problem with the freezer is that it is a coarse-grained solution. Therefore, what I believe we should do is to evolve in the directoin of more fine-grained solutions and gradually phase out the freezer. The kexec-based approach is an attempt to replace one coarse-grained solution (the freezer) with even more coarse-grained solution (stopping the entire kernel with everything), which IMO doesn't address the main problem. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
