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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
