[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: Matthew Garrett on 27 May 2010 10:40 On Thu, May 27, 2010 at 04:28:51PM +0200, Peter Zijlstra wrote: > On Thu, 2010-05-27 at 15:06 +0100, Matthew Garrett wrote: > > one way which indicates to the scheduler that tasks in TASK_RUNNING > > should be scheduled, and when the session is idle we set the flag the > > other way and all processes in that cgroup get shifted to > > TASK_INTERRUPTIBLE or something. > > What's wrong with simply making the phone beep loudly and displaying: > bouncing cows is preventing your phone from sleeping! Well, primarily that it's possible to design an implementation where it *doesn't* prevent your phone froms sleeping, but also because a given application may justifiably be preventing your phone from sleeping for a short while. What threshold do you use to determine the difference? -- Matthew Garrett | mjg59(a)srcf.ucam.org -- 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: Peter Zijlstra on 27 May 2010 10:50 On Thu, 2010-05-27 at 15:35 +0100, Matthew Garrett wrote: > On Thu, May 27, 2010 at 04:28:51PM +0200, Peter Zijlstra wrote: > > On Thu, 2010-05-27 at 15:06 +0100, Matthew Garrett wrote: > > > one way which indicates to the scheduler that tasks in TASK_RUNNING > > > should be scheduled, and when the session is idle we set the flag the > > > other way and all processes in that cgroup get shifted to > > > TASK_INTERRUPTIBLE or something. > > > > What's wrong with simply making the phone beep loudly and displaying: > > bouncing cows is preventing your phone from sleeping! > > Well, primarily that it's possible to design an implementation where it > *doesn't* prevent your phone froms sleeping, but also because a given > application may justifiably be preventing your phone from sleeping for a > short while. What threshold do you use to determine the difference? Whatever you want, why would the kernel care? You can create a whole resource management layer in userspace, with different privilidge/trust levels. Trusted apps may wake more than untrusted apps. Who cares. The thing is, you can easily detect what keeps your cpu from idling. What you do about it a pure userspace solution. You can use the QoS stuff to give hints, like don't wake me more than 5 times a minute, if with those hints an app still doesn't meet whatever criteria are suitable for the current mode, yell at it. Or adjust its QoS parameters for it. Heck, for all I care, simply SIGKILL the thing and report it once the user starts looking at his screen again. -- 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 Cox on 27 May 2010 11:00 > Now, if the user is playing this game, you want it to be scheduled. If > the user has put down their phone and the screen lock has kicked in, you > don't want it to be scheduled. So we could imagine some sort of cgroup > that contains untrusted tasks - when the session is active we set a flag I would hope not, because I'd rather prefer my app that used the screen to get the chance to save important data on what it was doing irrespective of the screen blank: "I have an elegant proof for this problem but my battery has gone flat" (and I imagine we can play that examples game forever given Ashby's law) > You can't express that with resource limits or QoS constraints. I don't see why not. You just have to think about the problem from the right end. Start from "normality is well behaved applications" and progress to "but I can constrain bogus ones". So what are the resource constraints/QoS constraints for your example: [Simplistically] 1. App says 'I want to wakeup from events for me within 1 second' (Because I like drawing cows at about that rate) 2. App open driver for buttons 3. App opens driver for screen Driver for buttons goes 'humm, well I can trigger wakeup from all power states so I need no restrictions'. Screen will vary by device a lot. (I'll come back to the screen a bit more in a moment) So lets consider the same binary App runs on OLPC like h/w The pm code goes 'well I can suspend/resume in a second thats cool' The screen code goes 'Hey I've got OLPC like video so thats ok' The button driver can wake the system from suspend and queue an event App runs on Android like h/w The pm code goes 'well I can suspend/resume in a second thats cool' The screen code goes 'Gee the screen goes blank if I go below level X' so I'll set a limit The button driver can wake the system from suspend and queue an event App runs on Android like h/w but not trusted The pm code goes 'well tough, you can't do that, I'll refuse you' (Maybe user space wrapped by Android with a 'Cows wants to eat your phone alive [Refuse] [This Time Only] [Always] UI User hits refuse and Android duly assigns the code no guarantee and a hard limit of no guarantee. The screen code goes 'tough' The button driver can wake the system etc Cows will get suspended for longer than one second whether it likes it or not App runs on a desktop PC The pm code goes 'well I can't do suspend/resume in 1 second, but I can do C6' The screen goes 'I need C6' The button driver goes 'I need C6' Same app in each case and a lot less syscalls. No pathalogical cases either - with suspend blockers you can get emergent synchronization patterns between applications where each app rarely blocks suspends but together their timings fall such that they never allow it. How do you propose to even detect that ? Ok now the screen If I write to an X server and the server doesn't wish to talk to me it ignores the stream and I block. This has been the case since the 1980s. What is the problem here - your device driver for the display can block tasks it doesn't want to use the display. -- 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 11:10 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. Opportunistic suspends are okay. The proposed userspace API is too Android-specific. More kernel mechanisms are needed for expressing processes' latency requirements. The last one is obviously a longer-term issue, so let's ignore it for now. That leaves as the only point of contention the userspace suspend-blocker API. The proposal I made a couple of days ago removes this API and leaves the other things (i.e., the in-kernel suspend blockers and opportunistic suspend) intact. In place of the userspace kernel-blocker API, Android would have to implement a power manager process that would essentially juggle all the latency requirements in userspace. Communication between the power manager process and the kernel would be limited to adding a new "opportunistic" entry to /sys/power/state -- something which could well be useful in its own right. Even if this API turns out not to be good, it's simple enough that it could be removed pretty easily. This answers Alan Cox's (and other's) desire not to implement a questionable or special-purpose API. And it also answers Thomas's desire to make scheduling decisions based on latency requirements (although the answer is simply to punt all these decisions out of the kernel and into userspace -- which is reasonable for now since the alternative would require a long-term kernel development effort). Indeed, having a power manager thread may well turn out to be a useful thing -- but even if it doesn't, this scheme minimizes the damage while still allowing the Android platform to use a vanilla kernel with only limited modifications to their userspace. 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/
From: Peter Zijlstra on 27 May 2010 11:10
On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote: > > Opportunistic suspends are okay. > > The proposed userspace API is too Android-specific. I would argue opportunistic suspends are not ok, and therefore the proposed API is utterly irrelevant. -- 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/ |