Messages in this thread | | | Date | Mon, 2 Aug 2010 07:44:29 +0200 | From | Florian Mickler <> | Subject | Re: 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
| |