Re: Attempted summary of suspend-blockers LKML thread, take three

[Rafael J. Wysocki]

On Saturday, August 07, 2010, Rafael J. Wysocki wrote:
> On Saturday, August 07, 2010, Ted Ts'o wrote:
> > On Fri, Aug 06, 2010 at 08:14:09PM -0700, david@xxxxxxx wrote:
> > > 
> > > that description sounds far more like normal sleep power management
> > > that suspending. especially since they want to set timers to wake
> > > the system up and the defining characteristic of suspend (according
> > > to this thread) is that timers don't fire while suspended.
> > > 
> > > as I am seeing it, there are two reasons why this don't "just work"
> > > 
> > > 1. sleeping can't currently save as much power as suspending
> > 
> > No, I don't think that's the case at all.  The key thing here is that
> > *most* applications don't need to be modified to use suspend locks,
> > because even though they might be in an event loop, when the user user
> > turns off the display, the user generally doesn't want it doing things
> > on their behalf.
> > 
> > Again, take for example the Mac Book, since Apple has gotten this
> > right for most users' use cases.  When you close the lid, you even if
> > the application is under the misguided belief that it should be
> > checking every five seconds to see whether or not the web page has
> > reloaded --- actually, that's not what you want.  You probably want
> > the application to be forcibly put to sleep.  So the whole point of
> > the suspend blocker design is that you don't have to modify most
> > applications; they just simply get put to sleep when you close the
> > MacBook lid, or, in the case of the Android device, you push the
> > button that turns off the screen.
> 
> But in principle that need not mean suspending the entire system.
> To get applications out of the way, you need to freeze user space.
> However, that's not sufficient, because in addition to that you need to
> prevent deactivate the majority of interrupt sources to avoid waking up the
> CPU (from C-states) too often.

s/prevent deactivate/deactivate/

Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/