* Matthew Garrett <mjg@redhat.com> [100507 12:29]:
Well there are obviously two paths to take, I think both of
them should work. The alternative to suspend blockers is:
- Implement a decent kernel idle function for the hardware and
use cpuidle to change the c states. The dyntick stuff should
already work for most hardware.
- Fix the core userspace apps to minimize timers.
- Deal with broken apps whichever way you want in the userspace.
- Optionally, do echo mem > /sys/power/state based on some
product specific logic in the userspace.
The advantage of this is that no kernel changes are needed,
except for implementing the custom idle function for the
hardware. And this kind of setup has been in use for about
five years.
And, you can keep the system running constantly if you have
hardware that supports good idle modes, then you don't even
need to suspend at all.
The core problems I see with suspend blockers are following,
please correct me if I'm wrong:
- It is caching the value of echo mem > /sys/power/state and
misusing it for runtime power management as the system still
keeps running after trying to suspend. Instead, the kernel
idle function and cpuidle should be used if the kernel keeps
running.
- They require patching all over the drivers and userspace.
- Once the system is suspended, it does not run. And the apps
don't behave in a standard way because the system does not
wake to timer interrupts.
I agree that we need to be able to echo mem > /sys/power/state
in an atomic way. So if there are problems with that, those
issues should be fixed.
Cheers,
Tony
--
