[PATCH 0/8] Suspend block api (version 8)
in [Kernel]
|
Prev: [ANN] Linux Security Summit 2010 - Announcement and CFP
Next: [PATCH 4/8] PM: suspend_block: Add debugfs file
From: Dmitry Torokhov on 27 May 2010 20:10 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-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Rafael J. Wysocki on 27 May 2010 20:40 On Friday 28 May 2010, 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 ? That's reasonable IMO. > - 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) > > I am curious Thomas how that would tie in with PI in the RT > world, it's effectively inheriting priority from the users finger. > > - Would a model where the UI side behaviour looked like > > Timeout > Screen Off > Set QoS of 'user apps' to QS_NONE > > Event > [Some chain of activity] > Screen On > Set QoS of 'user apps' to QS_ABOVESUSPEND > > do the job combined with the ability to see who is stopping us dropping > to suspend so user space can take action. This could be a data table > from the Android cpu manager provided to Android specific policy in > whoever owns the display. > > > If so how do we fix the UI policy code doing > > Screen Off > Button Press > task to QS_ABOVESUSPEND > task to QS_NONE > > without touching the app userspace code > > > Perhaps > > count2 = tasks to QS_NONE | QS_NOTCHANGED > Screen off > Button Press > task to QS_ABOVESUSPEND > count = tasks that are QS_NOTCHANGED to QS_NONE > > if (count != count2) { > Stuff happened ... rethink > } > > That is still a bit weird and wonderful but all the logic is in the right > places. The special magic remains in the Android policy code and in the > kernel specifics for Android. > > Thoughts ? Hmm. How do we prevent the "non-relevant" tasks from being scheduled once we've decided to go for power saving? Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Arve Hjønnevåg on 27 May 2010 20:50 On Thu, May 27, 2010 at 4:50 PM, Alan Cox <alan(a)lxorguk.ukuu.org.uk> 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 ? > This is a much harder question to answer that what we need to use opportunistic suspend. The question we ask is more like this: "Is all important work complete?". In the simplest case these can be the same, but on Android they are not. Some wakeup events require work to be performed in many processes. A thread that needs to respond to a wakeup event may currently be busy doing unimportant work. This could possibly be solved by saying all important work must be above priority N, but you would need full priority inheritance support and we are not there today. > - 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 > What happens if the user presses the button right before you set QoS of 'user apps' to QS_NONE? To me it looks like this solution would result in this sequence which may ignore the button press: � � � �Button pushed � � � �Button driver sets QoS of app it wakes to QS_ABOVESUSPEND � � � �Set QoS of 'user apps' to QS_NONE > � � � �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) Why is "wake_up_pri(&queue, priority)" more acceptable than "suspend_block(..."? > > � � � �I am curious Thomas how that would tie in with PI in the RT > � � � �world, it's effectively inheriting priority from the users finger. > > - Would a model where the UI side behaviour looked like > > � � � �Timeout > � � � �Screen Off > � � � �Set QoS of 'user apps' to QS_NONE > > � � � �Event > � � � �[Some chain of activity] > � � � �Screen On > � � � �Set QoS of 'user apps' to QS_ABOVESUSPEND > > �do the job combined with the ability to see who is stopping us dropping > �to suspend so user space can take action. This could be a data table > �from the Android cpu manager provided to Android specific policy in > �whoever owns the display. > > > If so how do we fix the UI policy code doing > > � � � �Screen Off > � � � � � � � � � � � � � � � � � � � �Button Press > � � � � � � � � � � � � � � � � � � � �task to QS_ABOVESUSPEND > � � � �task to QS_NONE > > without touching the app userspace code > > > Perhaps > What happens if the button press happend before this line: > � � � �count2 = tasks to QS_NONE | QS_NOTCHANGED > � � � �Screen off > � � � � � � � � � � � � � � � � � � � �Button Press > � � � � � � � � � � � � � � � � � � � �task to QS_ABOVESUSPEND > � � � �count = tasks that are QS_NOTCHANGED to QS_NONE > > � � � �if (count != count2) { > � � � � � � � �Stuff happened ... rethink > � � � �} > > That is still a bit weird and wonderful but all the logic is in the right > places. The special magic remains in the Android policy code and in the > kernel specifics for Android. > > Thoughts ? I don't think it works. Also, it does not seem much less invasive than suspend blockers. -- Arve Hj�nnev�g -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mike Chan on 27 May 2010 20:50 On Thu, May 27, 2010 at 5:05 PM, Rafael J. Wysocki <rjw(a)sisk.pl> wrote: > On Friday 28 May 2010, Alan Cox wrote: >> > The approach with user space power manager suggested by Dmitry and Alan Stern >> > may work, but it still assumes some kind of suspend blockers to be present in >> > the kernel. �If we reject that too, I wonder what approach Google is supposed >> > to use and still get the same battery life they get with suspend blockers. >> >> I'm getting less convinced it needs suspend blockers at all for this case, >> assuming that you are willing to have a policy that is based on >> >> - assuming apps play nicely >> - having the information to user space you need (who woke us, who blocked >> � us, events) >> - dealing with offenders primarily from user space using that information >> >> I'm fairly happy about the following so far >> >> - we should have a common interface for seeing some pm events (like >> � duh ?) but it does need careful thought so the watcher doesn't change >> � the behaviour and break it. (Message "We are suspending", gosh someone >> � is running to receive the message, resume being the obvious case) >> >> - Suspend is (for many platforms) just a cotinuation down the power >> � chain. Demonstrated and implemented on ARM. Very much the direction of >> � S0i1/S0i3 on x86 MID devices. Proved by the fact it has been done and >> � made to work, and by reading the Moorestown PR. >> >> - Given a non forced (that is 'idle down') transition to a suspend level >> � we can implement a 'suspend as idle' on many embedded platforms in a >> � manner which is not racy at kernel level. Apparently implemented >> � already on ARM >> >> - Given a non forced transition to such a suspend level and the reporting >> � of certain events we can do a full user space managed graphical UI type >> � environment policy in a race free fashion >> >> - With notification of who caused a resume and maybe a bit of other >> � general stat gathering it is possible to identify and handle abuses of >> � power resource. Proved by the fact we can do this with powertop but >> � more elegance in the interfaces would be nice. >> >> I am not sure if a pm event is what is needed for this or a sum 'hardware >> triggered wake up' event. >> >> I accept that current ACPI based laptops probably couldn't make use of >> such a feature but I don't think this is important at the moment. > > No, it's not. > >> A resource constraint model might help further in the ACPI case. It's >> useful for other stuff but it might well be a distraction and >> implementation detail in terms of the basic question about what is needed >> for something like Android. >> >> At this point the input of the Android team and the Nokia people would >> be rather more useful to me. > > OK, I added Arve and Brian to the CC list. > Even if we used the proposed QoS replacement, are there suggestions on how to keep the cpu idle for longer than 2 seconds in Linux without using suspend? On a thread somewhere I had real world power numbers on a Motorola Droid idling (screen off) with and without suspend blockers. -- Mike > Thanks, > Rafael > _______________________________________________ > linux-pm mailing list > linux-pm(a)lists.linux-foundation.org > https://lists.linux-foundation.org/mailman/listinfo/linux-pm > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on 27 May 2010 21:00
On Fri, 28 May 2010, Rafael J. Wysocki wrote: > > And the forced-suspend design relies on the fact that processes remain > > frozen throughout. If we leave some processes unfrozen and one of them > > somehow becomes runnable, that means we have to abort the forced > > suspend before the process is allowed to run. > > We could avoid that if drivers could block tasks, but there are questions to > answer. First off, how a driver is supposed to know when to block the task > using it and when to do its power management transparently for the task? > Second, how to intercept and block all possible interfaces that user space > can use to talk to drivers (how to intercept a task using mmapped device, for > example)? We talked about this a few years ago and decided it was not feasible. It would require substantial changes to every device driver. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |