* Matthew Garrett <mjg@xxxxxxxxxx> [100507 12:29]: > On Fri, May 07, 2010 at 12:28:37PM -0700, Tony Lindgren wrote: > > * Daniel Walker <dwalker@xxxxxxxxxx> [100507 12:01]: > > > On Fri, 2010-05-07 at 19:46 +0100, Matthew Garrett wrote: > > > > Freezer cgroups would work better, but it doesn't really change the > > > > point - if that application has an open network socket, how do you know > > > > to resume that application when a packet comes in? > > > > No idea, but that still sounds a better situation to me than > > trying to deal with that for a suspended system! :) > > Suspend blocks deal with that problem. Nobody has yet demonstrated a > workable alternative solution. 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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
