Re: Attempted summary of suspend-blockers LKML thread

[Rafael J. Wysocki]

On Wednesday, August 04, 2010, Matthew Garrett wrote:
> On Wed, Aug 04, 2010 at 11:30:44AM -0700, david@xxxxxxx wrote:
> > a couple days ago I made the suggestion to put non-privilaged tasks in a  
> > cgroup so that the idle/suspend decision code could ignore acitivity  
> > caused by this cgroup.
> >
> > in the second version wakeup events would be 'activity' that would be  
> > counted and therefor the system would not be idle. As for the race with  
> > suspending and new things happening, wouldn't that be handled the same 
> > way that it is in a normal linux box?
> 
> No! And that's precisely the issue. Android's existing behaviour could 
> be entirely implemented in the form of binary that manually triggers 
> suspend when (a) the screen is off and (b) no userspace applications 
> have indicated that the system shouldn't sleep, except for the wakeup 
> event race. Imagine the following:
> 
> 1) The policy timeout is about to expire. No applications are holding 
> wakelocks. The system will suspend providing nothing takes a wakelock.
> 2) A network packet arrives indicating an incoming SIP call
> 3) The VOIP application takes a wakelock and prevents the phone from 
> suspending while the call is in progress
> 
> What stops the system going to sleep between (2) and (3)? cgroups don't, 
> because the voip app is an otherwise untrusted application that you've 
> just told the scheduler to ignore.

I _think_ you can use the just-merged /sys/power/wakeup_count mechanism to
avoid the race (if pm_wakeup_event() is called at 2)).

Thanks,
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/