> 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.
