Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

Ok lets try and produce something more concrete. The control groups may
be the wrong tool but we've got several such tools already


Kernel involved
----------------
acquire:		mark myself important (into cgroup important)
acquire(timeout)	ditto, plus app timer/timeout handler
release:		mark myself unimportant (into cgroup downtrodden) 

All user
--------
isHeld:			app implementation internal
setReferenceCounted:	app implementation internal


In the idle manager [Androids own probably]

	if (member of ignored cgroup && in user space)
		ignore for idle purposes


In the Android code managing this [Android specific bits of
probably userspace]
	mark downtrodden as ignored
	mark downtrodden as not ignored


[Total kernel changes

	Ability to mark/unmark a scheduler control group as outside of
	some parts of idle consideration. Generically useful and
	localised. Group latency will do most jobs fine (Zygo is correct
	it can't solve his backup case elegantly I think)

	Test in the idling logic to distinguish the case and only needed
	for a single Android specific power module. Generically useful
	and localised]

So I put my phone down

	The UI manager gets told the phone is 'down'
	Ten seconds later it is still down
	It marks the downtrodden group as 'ignored'

	The idle logic goes
		Nothing to run powersave
		Still nothing
		Ooh 0.3 seconds of nothing
		Drop into suspend state


If I push the button we get an IRQ
We come out of power save
The app gets poked
The app may be unimportant but the IRQ means we have a new timeout of
    some form to run down to idle
The app marks itself important
The app stays awake for 60 seconds rsyncing your email
The app marks itself unimportant
Time elapses
We return to suspend


If you are absolutely utterly paranoid about it you need the button
driver to mark the task it wakes back as important rather than rely on
time for response like everyone else. That specific bit is uggglly but
worst case its just a google private patch to a few drivers. I understand
why Android wants it. The narrower the gap between 'we are doing nothing,
sit in lowest CPU on state' and 'we are off' the better the battery life
and the more hittable the condition.

Apart from that optional paranoia case my kernel now contains some
trivial changes of generic value that have nothing to do with suspend
blocking. Android has suspend blocking by choosing to use the generic
features in its own specific way and we need almost no code writing ?

Alan