On Fri, May 28, 2010 at 12:50:45AM +0100, Alan Cox wrote: > > That's correct, but to me the Arve's goal is simply to maximize battery life > > and he found experimentally that the longest battery life is achieved if > > system suspend is used whenever the system doesn't need to be active (from its > > user's perspective). This actually is different from "when the system is > > idle", because the system isn't idle, for example, when updatedb is running. > > However, from the user's perspective the updatedb process doesn't really need > > to run at this particular time, it can very well do it's job in parallel with > > the user typing or reading news. So, the system may very well be suspended > > when updatedb is running. > > This is where the original questions around QoS came in > > > Since I think we've now rejected the feature, do we have a clear picture about > > what the Android people should do _instead_ and yet keep the battery life they > > want? Because I don't think telling "let them do what they want, who cares" > > is right. > > Today "idle" means "no task running" > > If you are prepared to rephrase that as "no task that matters is running" > what would need to answer ? > > - How do we define who matters: QoS ? > > - Can you describe "idle" in terms of QoS without then breaking the > reliable wakeup for an event (and do you need to ?) > > Could this for example look like > > Set QoS of 'user apps' to QS_NONE > Button pushed > Button driver sets QoS of app it wakes to QS_ABOVESUSPEND > > That would I think solve the reliable wakeup case although > drivers raising a QoS parameter is a bit unusual in the kernel. > That would at least however be specific to a few Android drivers > and maybe a tiny amount of shared driver stuff so probably not > unacceptable. (wake_up_pri(&queue, priority); isn't going to > kill anyone is it - especially if it usually ignores the > priority argument) That should probably go into higher levels, not in individual drivers, so we should be able to limit spreading of wake_up_pri() or whatever throughout the tree. This particular case should be probably handled by evdev raising QoS of the user that is opened particular /dev/input/eventX. -- Dmitry -- 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
