lkml.org 
[lkml]   [2010]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: suspend blockers & Android integration

* Ingo Molnar <mingo@elte.hu> wrote:

> * tytso@mit.edu <tytso@mit.edu> wrote:
>
> > [...] Not only has the source code been made available, but hundreds of
> > engineering hours have been made trying to accomodate the demands of LKML
> > --- and LKML has said no to suspend blockers/wakelocks.
>
> I dont think you are being fair here, at all.
>
> Firstly, the suspend-blockers feature is not being rejected (fixing and
> extending suspend is a worthwile goal), it's just that various different
> schemes have been proposed by the people who'll eventually have to maintain
> that code down the line.

Btw., i'd like to summarize the scheduler based suspend scheme proposed by
Thomas Gleixner, Peter Zijlstra and myself. I found no good summary of it in
the big thread, and there are also new elements of the proposal:

- Create a 'deep idle' mode that suspends. This, if all constraints
are met, is triggered by the scheduler automatically: just like the other
idle modes are triggered currently. This approach fixes the wakeup
races because an incoming wakeup event will set need_resched() and
abort the suspend.

( This mode can even use the existing suspend code to bring stuff down,
therefore it also solves the pending timer problem and works even on
PC style x86. )

- Introduce a 'minimum wakeup latency' task attribute (task->latency),
settable via a scheduler syscall. This is an ABI that influences the kernel
how idle the system can go. (i.e. the equivalent of suspend blockers, just
not binary and not system-wide.)

- Solve crappy app confinement via the scheduler:

A first proposal was to use the existing cgroup mechanism, but we found
a different and probably more elegant solution:

We can slightly extend the scheduler and introduce another per task 'minimum
latency other tasks are allowed to run' scheduling attribute
(task->exclude_latency) - set via a scheduler syscall as well. (only
settable by privileged tasks - such as the screensaver.)

This allows a task to 'exclude' other tasks that dont have low-latency
requirements. Crappy apps would have a large latency value, so they'd
be idled out when a privileged task sets the exclusion level low enough.

In the case of Android, this would for example be used by the screensaver
to introduce different levels of runnability/idling.

[ Note that this scheme would also be useful in a completely different
scenario, for real-time tasks as well: it would allow extreme-RT tasks to
quiescence all lower prio tasks in a controlled manner. (even if the RT
task is sleeping) ]

- Controlled auto-suspend: drivers (such as input) could on wakeup
automatically set the 'minimum wakeup latency' value of wakee tasks to a
lower value. This automatically prevents another auto-suspend in the near
future: up to the point the wakee task increases its latency (via the
scheduler syscall) again and allows suspend again.

This means there will be no surprise suspends for a task that may take a
bit longer than usual to finish its work. [ Detail: this would only be done
for tasks that have a non-default (non-infinity) task->latency value - to
prevent the input driver from lowering latency values (and preventing
future suspends) just because some unaware apps are running and using input
drivers. ]

All in one, this scheme allows everything without exception that
suspend-blockers allows and supports all the important usecases:

- allows agressive auto-idling

- has no wakeup races

- allows crappy-app confinement and other finegrained suspend control

- it should be pretty easy to adopt by Android as well, as it goes
along similar principles of kernel automatisms combined with
user-space controlled task and system attributes.

It's straightforward to adapt and it is also more generic, more clean and more
flexible than suspend-blockers.

Please mention any remaining technical issues that may still be are
unaddressed.

Thanks,

Ingo


\
 
 \ /
  Last update: 2010-06-04 01:27    [W:0.179 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site