lkml.org 
[lkml]   [2010]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Attempted summary of suspend-blockers LKML thread
On Thu, 5 Aug 2010 07:33:59 +0200
Florian Mickler <florian@mickler.org> wrote:

> On Wed, 4 Aug 2010 16:10:03 -0700
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:

>
> No no. In the David-Lang-CGroup-Scheme[1](tm?) suspend-from-idle
> is used. For idle decision a certain subset of tasks is ignored.
>
> Where suspend is prevented by the trusted
> process in android-world taking a wakelock, here it would just prevent
> the system from going idle by arming timers.
>
> This would be pretty equivalent to the suspend-blocker scheme and not
> introduce new userspace api. But the downside is, as Arve pointed out,
> that now one can not get full-idle-power-leverage while suspend
> is blocked.
>
> [1] http://permalink.gmane.org/gmane.linux.kernel/1018452 and
> following
>
>
> Cheers,
> Flo
>

There are a few downsides that got mentioned already in reponse.. I got
a little lagged behind.

There are upsides to this approach like not
having a special purpose userspace api, conceptually integrating
suspend into the idle mechanism ..

Short summary of the cons that got mentioned:

- applications need to resort to polling to keep the system
out of idle (-> system will never be fully idle)

- the race between deciding to suspend and becoming active
again is not handled

- no special statistics available

- the timers of the ignored applications will behave unexpected
(as the monotonic clock is not stopped)... while applications
have already to cope with network-loss, other side effects of
suspend without monotonic clock stopped are to be expected...


Cheers,
Flo


\
 
 \ /
  Last update: 2010-08-05 07:59    [W:0.581 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site