On Sun, 1 Aug 2010 22:06:34 -0700 (PDT)
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?
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.