Message-ID: <alpine.DEB.2.00.1008041554580.6545@asgard.lang.hm>
Date:	Wed, 4 Aug 2010 15:56:42 -0700 (PDT)
From:	david@...g.hm
To:	Arve Hjønnevåg <arve@...roid.com>
cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	pavel@....cz, florian@...kler.org, stern@...land.harvard.edu,
	swetland@...gle.com, peterz@...radead.org, tglx@...utronix.de,
	alan@...rguk.ukuu.org.uk
Subject: Re: Attempted summary of suspend-blockers LKML thread

On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:

> On Wed, Aug 4, 2010 at 3:31 PM,  <david@...g.hm> wrote:
>> On Wed, 4 Aug 2010, Matthew Garrett wrote:
>>
>>> On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote:
>>>>
>>>> On Wednesday, August 04, 2010, Matthew Garrett wrote:
>>>>>
>>>>> 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)).
>>>
>>> Yes, I think that solves the problem. The only question then is whether
>>> it's preferable to use cgroups or suspend fully, which is pretty much up
>>> to the implementation. In other words, is there a reason we're still
>>> having this conversation? :) It'd be good to have some feedback from
>>> Google as to whether this satisfies their functional requirements.
>>
>> the proposal that I nade was not to use cgroups to freeze some processes and
>> not others, but to use cgroups to decide to ignore some processes when
>> deciding if the system is idle, stop everything or nothing. cgroups are just
>> a way of easily grouping processes (and their children) into different
>> groups.
>>
>
> That does not avoid the dependency problem. A process may be waiting
> on a resource that a process you ignore owns. I you ignore the process
> that owns the resource and enter idle when it is ready to run (or
> waiting on a timer), you are still effectively blocking the other
> process.

and if you don't have a wakelock the same thing will happen. If you expect 
the process to take a while you can set a timeout to wake up every 30 
seconds or so and wait again, this would be enough to prevent you from 
going to sleep (or am I misunderstanding how long before you go into 
suspend without a wakelock set, see my other e-mail for the full question)

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

Powered by blists - more mailing lists