> On Mon, 2 Aug 2010, Paul E. McKenney wrote:
>
>> On Sun, Aug 01, 2010 at 10:06:34PM -0700,
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?
>>
>> Why not flesh this out and compare it to the draft requirements?
>> (I expect to be sending another version by end of day Pacific Time.)
>>
>> The biggest issue I see right off-hand is that a straightforward
>> implementation of your idea would require moving processes from one
>> cgroup to another when acquiring or releasing a suspend blocker, which
>> from what I understand would be way to heavyweight. On the other hand,
>> if acquiring and releasing a suspend blocker does not move the process
>> from one cgroup to another, then you need something very like the
>> suspend-blocker mechanism to handle those processes that are permitted
>> to acquire suspend blockers, and which are thus not a member of the
>> cgroup in question.
>>
>> That said, I did see some hint from the Android guys that it -might-
>> be possible to leverage cgroups in the way that you suggest might help
>> save power during times when suspend was blocked but (for example) the
>> screen was turned off. The idea would be to freeze the cgroup whenever
>> the screen blanked, even if suspend was blocked. The biggest issue
>> here is that any process that can hold a suspend blocker must never to
>> an unconditional wait on any process in this cgroup. Seems to me that
>> this should be possible in theory, but the devil would be in the details.
>>
>> If I am misunderstanding your proposal, please enlighten me!
>
> you are close, but I think what I'm proposing is actually simpler (assuming
> that the scheduler can be configured to generate the appropriate stats)
>
> my thought was not to move applications between cgroups as they
> aquire/release the suspend-block lock, bur rather to say that any
> application that you would trust to get the suspend-block lock should be in
> cgroup A while all other applications are in cgroup B
>
> when you are deciding if the system shoudl go to sleep because it is idle,
> ignore the activity of all applications in cgroup B
>
> if cgroup A applications are busy, the system is not idle and should not
> suspend.
>
