On Thu, 12 Jul 2007, Mark Lord wrote:
Rafael J. Wysocki wrote:
On Thursday, 12 July 2007 08:43, david@xxxxxxx wrote:
> On Wed, 11 Jul 2007, Jeremy Fitzhardinge wrote:
>
> > Andrew Morton wrote:
..
> 8. hibernate kernel does syspend-to-ram to put the devices into a known
> safe state.
Again, the devices should be quiesced rather then suspended in this step.
That's just not possible. The Hibernate kernel will not have all
of the same device drivers as the mainline kernel. Or at least that's
what people have previously stated here.
devices that have not been touches don't need to be quiesced or put into a
low-power state, they are still waiting to be initialized. so as long as
the device initialization can be done from the low-power or quiesced state
things will work just fine.
..
> > > This sounds awesome. Am I correct in expecting that ultimately the
> > > existing hibernation implementation just goes away and we reuse
> > > (and hence
> > > strengthen) the existing kexec (and kdump?) infrastructure?
No, not so simple. We still need much of the code to santize devices
upon wakeup from hibernation. And adding this extra reboot-kernel step
in the midst of hibernate will double the time it takes (ugh).
Currently, TuxOnIce(suspend2) takes about 10 seconds to suspend my notebook.
Switching to this new scheme would double that to 10 seconds to boot/probe,
plus the original 10 seconds to hibernate. Assuming the new implementation
even comes close to suspend2 speed.
why do you assume that it will take 10 seconds to boot the new kernel?
linuxbiosdoes it in <2 seconds, someone else posted on this thread <5
seconds
And the complexity and difficulty of setup really scares me.
Right now, we've got a pretty good/fast in-kernel (well, external patch)
that allows my machines to hibernate very quickly, wake up even faster,
and not swap like mad afterwards. Without any external programs,
initramfs, or extra kernels required.
And we want to replace this with an ultra-complex setup because.. ????
the complexity of the freezer freezing some things, but not other things
keeps getting t wrong and many people can't think of any algorithm that
will always get it right. This approach bypasses the entire problem
makeing it much simpler conceptually, even though there are a few more
parts involved.
David Lang
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
