Message-ID: <AANLkTiknyohok23S7dob=Tb1+PZp1QqZgwckcVDWMSe9@mail.gmail.com>
Date:	Wed, 4 Aug 2010 16:40:47 -0700
From:	Arve Hjønnevåg <arve@...roid.com>
To:	david@...g.hm
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

2010/8/4  <david@...g.hm>:
> On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
>
>> 2010/8/4  <david@...g.hm>:
>>>
>>> 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
>>
>> Not the same thing. If you don't hold a wakelock the entire system
>> will suspend and when it wakes up it continues where it left off.
>> Timeout still have time left before they expire.
>
> in what I'm proposing, if the 'privilaged/trusted" processes are idle long
> enough the entire system will suspend, and when it wakes up everything will
> continue to process normally
>

If you are triggering a system suspend from idle (I assume all cpus
idle), you also have to consider when to resume. You cannot abort
suspend just because a cpu is not idle anymore, since suspend itself
will wake up threads.

>>> 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
>>
>> I don't think polling is an acceptable solution to this problem. You
>> user space code know needs to know what "idle" timeout you have
>> selected so it can choose a faster poll rate. When is it safe to stop
>> polling?
>
> I think the timeouts are of such an order of magnatude that the polling can
> be infrequent enough to not be a significant amount of load, but be faster
> than any timeout
>

How do you ever enter suspend in this system? Currently timers in the
kernel and trusted user space code causes a significant power draw and
you want insignificant timers to prevent suspend.

>>> 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)
>>>
>>
>> We suspend as soon as no wakelocks are held. There is no delay.
>
> So, if I have a bookreader app that is not allowed to get the wakelock, and
> nothing else is running, the system will suspend immediatly after I click a
> button to go to the next page? it will not stay awake to give me a chance to
> read the page at all?
>
> how can any application run without wakelock privilages?

A wakelock is active when the screen is on.

-- 
Arve Hjønnevåg
--
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