> On Mon, 2 Aug 2010 00:02:04 -0700 (PDT)
>
david@lang.hm wrote:
>
>> 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.
>>>>>
>>> b) you can't use cgroup for other purposes anymore. I.e. if you want to
>>> have 2 groups that each only have half of the memory available, how
>>> would you then integrate the cgroup-ignore-for-idle-approach with this?
>>
>> two answers to this
>>
>> 1. does this matter? do you really need to combine this 'suspend, even if
>> there are processes trying to run' with other cgroup limitations?
>>
>> 2. who says that this must be limited to one cgroup? a cgroup can have
>> several different flags/limits set on it, so why can't one of them be this
>> 'ignore for suspend' flag?
>>
>> these seem like simple issues, what I don't know is if it's possible for
>> the process that controlls suspend to follow such a flag without major
>> surgury on it's innards (if it can, this seems like a easy win, but I can
>> imagine internal designs where the software just knows that _something_ is
>> trying to run and would have a very hard time figuring out what)
>>
>> David Lang
>
> Well, i fear it becomes some sort of parallel-tree structure...
> If you want a cgroups-partitioning for one kind of attribute you now
> need 2 containers for every possible stamping of that attribute... one
> being flagged with 'ignore-for-suspend-decision' and one without that
> flag.
> Do you see what I'm getting at, or do I need more coffee and it is
> irelevant to this concept?
