Re: Attempted summary of suspend-blockers LKML thread

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Wed, Aug 04, 2010 at 03:56:42PM -0700, david@lang.hm wrote:
> On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
> 
> >On Wed, Aug 4, 2010 at 3:31 PM,  <david@lang.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)

The difference between the Android scheme and your proposal is that the
Android scheme freezes -all- the processes, not just a subset of them.
Therefore, in the Android scheme, the case of one process attempting to
acquire a resource held by a frozen process.  In contrast, any scheme
that attempts to freeze only a subset of the processes must somehow
either avoid or properly handle the situation where a frozen process is
holding a resource that a running process is trying to acquire.

							Thanx, Paul