lkml.org 
[lkml]   [2010]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Attempted summary of suspend-blockers LKML thread
On Sun, 1 Aug 2010 22:06:34 -0700 (PDT)
david@lang.hm wrote:

> On Sun, 1 Aug 2010, Arjan van de Ven wrote:
>
> > I'm a little worried that this whole "I need to block suspend" is
> > temporary. Yes today there is silicon from ARM and Intel where suspend
> > is a heavy operation, yet at the same time it's not all THAT heavy
> > anymore.... at least on the Intel side it's good enough to use pretty
> > much all the time (when the screen is off for now, but that's a memory
> > controller issue more than anything else). I'm pretty sure the ARM guys
> > will not be far behind.
>
> remember that this 'block suspend' is really 'block overriding the fact
> that there are still runable processes and suspending anyway"
>
> having it labeled as 'suspend blocker' or even 'wakelock' makes it sound
> as if it blocks any attempt to suspend, and I'm not sure that's what's
> really intended. Itsounds like the normal syspend process would continue
> to work, just this 'ignore if these other apps are busy' mode of operation
> would not work.
>
> which makes me wonder, would it be possible to tell the normal idle
> detection mechanism to ignore specific processes when deciding if it
> should suspend or not? how about only considering processes in one cgroup
> when deciding to suspend and ignoring all others?
>
> David Lang

We then get again to the "runnable tasks" problem that was
discussed earlier... the system get's "deadlock-prone" if a subset of
tasks is not run.
Interprocess dependencies are not so easy to get right in general.

Cheers,
Flo


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