Re: Attempted summary of suspend-blockers LKML thread
From: Rafael J. Wysocki
Date: Wed Aug 04 2010 - 16:52:29 EST
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)).
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/