Message-ID: <alpine.DEB.2.00.1008020200450.25170@asgard.lang.hm>
Date:	Mon, 2 Aug 2010 02:06:55 -0700 (PDT)
From:	david@...g.hm
To:	Florian Mickler <florian@...kler.org>
cc:	Arjan van de Ven <arjan@...radead.org>, paulmck@...ux.vnet.ibm.com,
	"Ted Ts'o" <tytso@....edu>, linux-pm@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, arve@...roid.com,
	mjg59@...f.ucam.org, pavel@....cz, rjw@...k.pl,
	stern@...land.harvard.edu, swetland@...gle.com,
	peterz@...radead.org, tglx@...utronix.de, alan@...rguk.ukuu.org.uk
Subject: Re: Attempted summary of suspend-blockers LKML thread

On Mon, 2 Aug 2010, Florian Mickler wrote:

> On Mon, 2 Aug 2010 00:02:04 -0700 (PDT)
> david@...g.hm wrote:
>
>> On Mon, 2 Aug 2010, Florian Mickler wrote:
>>
>>> On Mon, 2 Aug 2010 08:40:03 +0200
>>> Florian Mickler <florian@...kler.org> wrote:
>>>
>>>> On Sun, 1 Aug 2010 23:06:08 -0700 (PDT)
>>>> david@...g.hm wrote:
>>>>
>>>>> On Mon, 2 Aug 2010, Florian Mickler wrote:
>>>>>
>>>>>> On Sun, 1 Aug 2010 22:06:34 -0700 (PDT)
>>>>>> david@...g.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?

yes, it could mean a doubleing in the number of cgroups that you need on a 
system. and if there are other features like this you can end up in a 
geometric explosion in the number of cgroups.

in practice I question if there is likely to be a need for this sort of 
thing on a system that's complex enough to use cgroups for other purposes.

in particular, in this case the 'ignore for syspend' flag is not going to 
be set for programs that are trusted to be well behaved. Such programs are 
unlikely to be placed under other restraints (because they _are_ trusted 
to be well behaved)

David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists