Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Thursday 13 May 2010, Tony Lindgren wrote:
> * Alan Stern <stern@rowland.harvard.edu> [100513 14:32]:
> > On Thu, 13 May 2010, Tony Lindgren wrote:
> > 
> > > The difference between echo mem > /sys/power/state and suspend blocks
> > > is that with suspend blocks the system keeps running.
> > 
> > Irrelevant.  Paul wasn't talking about the suspend blockers; he was 
> > talking about opportunistic suspend.  So what's the difference between 
> > opportunistic suspend and "echo mem >/sys/power/state"?  Especially 
> > when suspend blockers aren't being used?
> 
> Opportunistic suspend is really trying to do runtime PM, see below.

NO, IT IS NOT!  What it does is to detect situations in which it is desirable
to put the _entire_ _system_ to sleep, while runtime PM works on a per-device
basis.

> > > And that's why 
> > > it should be handled by runtime power management instead.
> > 
> > Runtime PM is not capable of freezing userspace and shutting down CPUs.  
> > More or less by definition -- if it could then it wouldn't be "runtime" 
> > any more, since the processor wouldn't be running.
> 
> Not true. We are already powering off CPUs and rebooting them for
> at least omaps in every idle loop using cpuidle. The memory stays on.

What about user space, though?  Do you freeze it?

> > > The suspend blocks seems like a hack to spam filter good and bad
> > > apps from timer usage point of view. Applications are categorized
> > > as good or bad depending if they grab a susped blocker or not.
> > 
> > You're referring just to the userspace part of the suspend blocker 
> > API.  What about the kernel part?
> 
> IMHO some timer flags should be used in the kernel too. Currently
> there's no way of knowing which timers are good or bad from suspend
> point of view.

How is that answering the Alan's question?

Rafael