Message-ID: <20100802092347.692dac32@schatten.dmk.lab>
Date:	Mon, 2 Aug 2010 09:23:47 +0200
From:	Florian Mickler <florian@...kler.org>
To:	david@...g.hm
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 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.
> >>>
> >>> 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.

hmm... i envisioned a mechanism where applications would be able to
switch the groups freely depending on what context the device is in. 
I didn't even thought about a static grouping. But maybe that is
possible also and maybe even sufficient...

Anyway... right. This is probably not a show-stopper.
 
> > 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?

Cheers,
Flo
--
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