> On Mon, 2 Aug 2010, Florian Mickler wrote:
>
> > On Mon, 2 Aug 2010 08:40:03 +0200
> > Florian Mickler <florian@mickler.org> wrote:
> >
> >> On Sun, 1 Aug 2010 23:06:08 -0700 (PDT)
> >>
david@lang.hm wrote:
> >>
> >>> On Mon, 2 Aug 2010, Florian Mickler wrote:
> >>>
> >>>> 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.
> >>>
> >>> I'm not suggesting that you don't run the 'untrusted' tasks, just that you
> >>> don't consider them when deciding if the system can suspend or not. if the
> >>> system is awake, everything runs, if the system is idle (except for the
> >>> activity of the 'untrusted' tasks) you suspend normally.
> >>>
> >>> David Lang
> >>
> >> Ah, yes. Sorry. It's pretty early in the morning over here, I don't
> >> seem to have my eyes fully opened yet... A "ignore-these-processes"
> >> cgroup could probably work... It would have the advantage of not having
> >> to maintain a special purpose API....
> >>
> >>
> >> Cheers,
> >> Flo
> >>
> >
> > Thinking about it.. I don't know much about cgroups, but I think a
> > process can only be in one cgroup at a time. So you'd need to provide
> >
> > a) a way to race free migrate them to the "suspend block" cgroup (or
> > dropping them out of the "ignore" cgroup)
>
> why does it need to be race free? being in transition is going to be
> logically the same as being in the other group.
>
> it's not like applications will be moving back and forth between the two
> groups is it? I expect that this would be a one-time thing at startup.
