lkml.org 
[lkml]   [2010]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Attempted summary of suspend-blockers LKML thread
Date
On Wednesday, August 04, 2010, Matthew Garrett wrote:
> On Wed, Aug 04, 2010 at 11:30:44AM -0700, david@lang.hm 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


\
 
 \ /
  Last update: 2010-08-04 22:55    [W:0.422 / U:0.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site