[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: Alan Cox on 27 May 2010 19:50 > 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) 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 ? -- 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: Kevin Hilman on 27 May 2010 19:50 Alan Cox <alan(a)lxorguk.ukuu.org.uk> writes: > - 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 Just to confirm, yes, it is already implemeted on ARM, and in mainline for the TI OMAP3 (ARM Cortex-A8) and in commercial products (Nokia N900, Moto Droid, Palm Pre, Archos, etc.) For the OMAP the deepest C-state is actually a fully powered-down ARM core. While the Droid uses 'suspend as idle' in addition to opportunistic suspend, the N900 *never* suspends in the traditional sense, it is entirely idle based. Kevin -- 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 19:50 On Friday 28 May 2010, Alan Cox wrote: > On Thu, 27 May 2010 23:55:13 +0200 > "Rafael J. Wysocki" <rjw(a)sisk.pl> wrote: > > > On Thursday 27 May 2010, Alan Cox wrote: > > > > > If one works so does the other. > > > > > > > > Not at all. The entire point of opportunistic suspend is that I don't > > > > care is currently in TASK_RUNNABLE or has a timer that's due to expire > > > > in 100msec - based on policy (through not having any held suspend > > > > blockers), I'll go to sleep. That's easily possible on PCs. > > > > > > Yes I appreciate what suspend blockers are trying to do. Now how does > > > that connect with my first sentence ? > > > > I guess what Matthew wanted to say was that you couldn't use ACPI S3 as > > a very deep CPU idle state, because of the way wakeup sources are set up > > for it, while you could use it for aggressive power management with suspend > > blockers as proposed by Arve. > > Which is a nonsense. Because the entire Gnome desktop and KDE, and > OpenOffice and Firefox and friends would need fitting out with > suspend blockers. > > x86 hardware is moving to fix these problems (at least on handheld > devices initially). Look up the C6 power idle, and S0i1 and S0i3 > standby states. I reckon the laptop folks can probably get the hardware > fixed well before anyone can convert the entire PC desktop to include > blockers. To clarify, I'm not suggesting to spread suspend blockers all over the universe. 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:00 On Thu, May 27, 2010 at 4:43 PM, Rafael J. Wysocki <rjw(a)sisk.pl> wrote: > On Thursday 27 May 2010, Thomas Gleixner wrote: >> On Thu, 27 May 2010, Rafael J. Wysocki wrote: >> >> > On Thursday 27 May 2010, Thomas Gleixner wrote: >> > > On Thu, 27 May 2010, Alan Stern wrote: >> > > >> > > > On Thu, 27 May 2010, Felipe Balbi wrote: >> > > > >> > > > > On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote: >> > > > > >If people don't mind, here is a greatly simplified summary of the >> > > > > >comments and objections I have seen so far on this thread: >> > > > > > >> > > > > > � � The in-kernel suspend blocker implementation is okay, even >> > > > > > � � beneficial. >> > > > > >> > > > > I disagree here. I believe expressing that as QoS is much better. Let >> > > > > the kernel decide which power state is better as long as I can say I >> > > > > need 100us IRQ latency or 100ms wakeup latency. >> > > > >> > > > Does this mean you believe "echo mem >/sys/power/state" is bad and >> > > > should be removed? �Or "echo disk >/sys/power/state"? �They pay no >> > > >> > > mem should be replaced by an idle suspend to ram mechanism >> > >> > Well, what about when I want the machine to suspend _regardless_ of whether >> > or not it's idle at the moment? �That actually happens quite often to me. :-) >> >> Fair enough. Let's agree on a non ambigous terminology then: >> >> � � �forced: >> >> � � � � � �suspend which you enforce via user interaction, which >> � � � � � �also implies that you risk losing wakeups depending on >> � � � � � �the hardware properties > > OK > >> � � �opportunistic: >> >> � � � � � �suspend driven from the idle context, which guarantees to >> � � � � � �not lose wakeups. Provided only when the hardware does >> � � � � � �provide the necessary capabilities. > > I can accept that definition, but this is not what "opportunistic" means in the Is there a difference between this new definition of opportunistic and idle? I assume suspend here means low a low power sleep state since it is impossible to initiate and abort Linux suspend from idle since initiating suspend will cause the system to become not idle. > Arve's changelogs. �What it means there is that he wants the system to suspend > even when it is not technically idle (like in the updatedb example I gave in a > previous message). �Suspend blockers are supposed to be a mechanism by which > the kernel and user space together may determine when to suspend (and it's > somewhat orthogonal to idle). > -- 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: Rafael J. Wysocki on 27 May 2010 20:10
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. Thanks, 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/ |