Suspend block api (version 6)
in [Kernel]
|
Prev: mm: fix race between shift_arg_pages and rmap_walk
Next: [PATCH -next] power: fix block_io.c printk warning
From: Mark Brown on 5 May 2010 16:20 On Wed, May 05, 2010 at 04:04:00PM -0400, Alan Stern wrote: > P.S.: What happens if a suspend occurs while a call is in progress, so > the codec is left powered up, and then the call ends? Does the system > wake up at that point? Or does it stay suspended with the codec still > powered, even though it's not needed any more? Call end will be a system wake event in pretty much all systems, userspace will want to do some work when the call goes away anyway. Anyone who doesn't do that will see the CODEC stay powered, hopefully the baseband will send it a nice mute signal instead of popping. -- 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: Mark Brown on 5 May 2010 16:20 On Wed, May 05, 2010 at 09:02:43PM +0100, Matthew Garrett wrote: > One thing that's been mentioned before is that some vendors can swap the > kernel much more easily than they can swap userspace, with the added > constraint that they have little control over the bootloader. So if > there's a userspace interface, it may well also be helpful to provide a > kernel hook to allow the platform setup code to configure things. But Oh, there's definitely going to be a platform-specific hook to configure things. The platform needs to specify how the devices that make up the audio subsystem are interconnected on the board, and that's done in kernel since it depends on the hardware and can potentially lead to physical damage if done incorrectly. > otherwise, I think that'd work for audio - the only question is whether > we need it to be more generic. Agreed. -- 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 5 May 2010 16:30 On Wednesday 05 May 2010, Alan Stern wrote: > On Wed, 5 May 2010, Matthew Garrett wrote: > > > On Wed, May 05, 2010 at 03:20:40PM -0400, Alan Stern wrote: > > > > > One the face of it, a runtime-PM solution would dictate that the > > > codec's driver ought to turn off the codec whenever the driver thinks > > > it isn't being used. Ergo, if the driver didn't know when a call was > > > in progress, it would use runtime PM to turn off the codec during a > > > call. > > > > Well, part of the problem is that right now most of our beliefs about > > imposed constraints tend to be based on what userspace is doing - "Don't > > power down the audio codec when userspace has it open", for instance. > > But that goes away with opportunistic suspend. In most cases you don't > > want the audio codec to stay awake just because userspace was using it > > to make bouncing cow noises, especially if you've just frozen userspace. > > So the problem becomes more complicated than it would otherwise be. > > It sounds like the problem can be stated simply enough: At the moment, > nobody knows when the codec should be powered down! Userspace might > have some idea, but even if its ideas are right it has no way of > communicating them to the kernel. > > The power/control sysfs attribute was intended for just that purpose, > although it was aimed at runtime PM rather than system PM. > Nevertheless, it or something like it could be used. Of course, there > would still remain the issue of userspace telling the kernel not to > power down the codec while making bouncing cow noises -- but at this > point it's not really a kernel problem any more. We'd need a separate control, I think. The problem is, though, that the Android user space, for example, doesn't use the sysfs attributes of devices, so this control wouldn't be particularly useful for it. > P.S.: What happens if a suspend occurs while a call is in progress, so > the codec is left powered up, and then the call ends? Does the system > wake up at that point? Or does it stay suspended with the codec still > powered, even though it's not needed any more? I guess you end up telling the user that the call ended, so the system wakes up. That's only a guess, though. 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: Mark Brown on 5 May 2010 16:30 On Wed, May 05, 2010 at 03:55:34PM -0400, tytso(a)mit.edu wrote: > I confess I've completely lost track of (a) what problem you are > trying to solve, and (b) how this might relate to some change that > you'd like to see in the suspend block API. Could you do a quick > summary and recap? I've gone over the entire thread, and it's still > not clear what change you're advocating for in suspend blockers. The issue isn't suspend blockers, it's the opportunistic suspend stuff that goes along with them. When that is in use the system suspends vastly more aggressively, including in situations where a runtime PM based approach like mainline had been adopting would not suspend since some devices still need to be active, the classic case being keeping the audio subsystem and baseband live when in a phone call. This problem did not appear to have been considered as things stood. I'm not really advocating a change in what's there. What I'm looking for is some sort of agreement as to how subsystems and drivers that need to not act on suspend requests from the core in these situations should do that. If there is a generic solution it'd probably be an additional mostly orthogonal interface rather than a change to what's being proposed here. What we look like we're converging on is a subsystem/driver local solution since it doesn't look like a terribly widespread problem. That's totally OK, it's just that as I have said I don't want to go off and do that without the general PM community being aware of it so we avoid anyone running into nasty surprises further down the line. -- 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: mark gross on 5 May 2010 16:40
On Mon, May 03, 2010 at 09:40:26AM -0700, Kevin Hilman wrote: > Arve Hj�nnev�g <arve(a)android.com> writes: > > > This patch series adds a suspend-block api that provides the same > > functionality as the android wakelock api. This version fixes a race > > in suspend blocking work, has some documentation changes and > > opportunistic suspend now uses the same workqueue as runtime pm. > > Earlier this month, several folks intersted in embedded PM had a BoF > as part of the Embedded Linux Conference[1] in San Francisco. Many of > us had concerns about wakelocks/suspend-blockers and I wanted to share > some of mine here, since I don't know if embedded folks (other than > Google) were included in discussions during the LF Collab summmit. > > I hope other embedded folks will chime in here as well. My background > is in embedded as one of the kernel developers on the TI OMAP SoCs, > and I work primarily on PM stuff. > > My comments are not about this implementation of suspend blockers in > particular, but rather on the potential implications of suspend > blockers in general. I also think we need to take a hard look at the process here. --mgross > Sorry for the lengthy mail, it's broken up in to 3 parts: > > - suspend blockers vs. runtime PM > - how to handle PM aware drivers? > - what about dumb or untrusted apps > > > Suspend blockers vs runtime PM > ------------------------------ > > My primary concern is that suspend blockers attempt to address the > same problem(s) as runtime PM, but with a very different approach. > Suspend blockers use one very large hammer whereas runtime PM hands > out many little hammers. Since I believe power management to be a > problem of many little nails, I think many little hammers are better > suited for the job. > > Currently in the kernel, we have two main forms of PM > > - static PM (system PM, traditional suspend/resume etc.) > - dynamic PM (runtime PM, CPUfreq, CPUidle, etc.) > > And with the addition of suspend blockers we have something in > between. In my simple world, I think of suspend_blockers as static PM > with a retrofit of some basic dynamic capabilities. In my view, a > poor man's dynamic PM. > > The current design of suspend blockers was (presumably) taken due to > major limitations and/or problems in dynamic PM when it was designed. > However, since then, some very signifcant improvements in dynamic PM > have come along, particularily in the form of runtime PM. What I > still feel is missing from this discussion are details about why the > issues addressed by suspend blockers cannot be solved with runtime PM. > > It seems to me the keypad/screen example given in the doc can very > easily be solved with runtime PM. The goal of that example is that > the keypad not turn on the screen unless a specific key is pressed. > That is rather easy to accomplish using runtime PM: > > 1. system is idle, all devices/drivers runtime suspended > (display and keypad drivers are both runtime suspended) > - keypress triggers wakeup ->runtime_resume() of keypad (screen is > still runtime suspended) > - key press trickles up to userspace > - keypad driver is done, goes idle and is runtime supended > - userspace decides whether or not to turn on screen based on key > - if not, goto 1, (display is still runtime suspended) > - if so, start using display and it will be runtime resumed > > I realize this keypad example was only one example usage of suspend > blockers, but I suspect the others would be solved similarily using > runtime PM. > > But anyways, to get back to the main point: > > I feel the main problems tackled by _kernel_ suspend blockers (as I > understand them) are the same problems already addressed by runtime > PM. First and formost, both have the same guiding principle: > > Rule #1: Always try for lowest power state, unless X > > For runtime PM, X = "activity" > For suspend blockers, X = a held suspend_blocker > > In addition, both have the same secondary goals: > > - keep device PM independent of other devices (e.g. don't wake up > screen just because keypad was pressed) > > - wakeups/events can be handled in a device specific way, without > affecting other devices or rest of the system, unless desired > > So, the goals are the same, but the approaches are different. Runtime > PM makes each of the drivers and subsystems do the work, where suspend > blockers just forces the issue from on high. IMHO, the more flexible > and generic approach of runtime PM is more suited to a general purpose > kernel than the one-big-hammer approach currently taken by suspend > blockers. > > > What about PM aware drivers? > ---------------------------- > > All of this brings up a second major concern regarding how to write PM > aware drivers. > > At least from the kernel perspective, both suspend blockers and > runtime PM have the same goal. Given that, which framework should the > driver writer target? Both? Seems like duplicate effort. Using > suspend blockers assumes the system is in opportunitstic suspend mode > and (at least in the keypad example given) assumes a suspend-blocker > aware userspace (Android.) Without both, targeted power savings will > not be acheived. > > To me, runtime PM is a generic and flexible approach that can be used > with any userspace. Driver writers should not have to care whether > the system is in "opportunistic" mode or about whether userspace is > suspend blocker capable. They should only have to think about when > the device is (or should be) idle. > > >From my experience with OMAP, we *really* do not want to care about > what userspace is or isn't capable of, or what suspend-mode the kernel > is in. Among other things, the OMAP linux kernel is used in the Nokia > N900 (Maemo), the Motorola Droid (Android) and the Palm Pre (webOS). > Comments on the future of each SW stack aside, we really want to run > the same kernel and drivers across all of those platforms as well as > whatever comes next. > > > What about dumb or untrusted apps? > --------------------------------------- > > In my view, the truly significant difference between suspend blockers > and runtime PM is what happens to userspace. So far, to me the only > compelling argument for suspend blockers is the goal of forcibly > shutting down userspace and thus forcing the system into idle > (although drivers could still reject a suspend request.) > > Again, since suspend blockers were designed, there have been major > efforts to track and fix userspace as well as underlying timer issues > (deferrable timers, coalescing, timer slack ...) that led to > unnecessary wakeups from userspace. Wouldn't it be better to spend > our collective efforts in continuing in that direction instead of just > hiding the underlying problems by forcing suspend? Fixing the root > causes will be better for everyone, not just those using Android. > > And if untrusted userspace apps remain as the major problem, maybe we > should aim for a solution directly targetting that problem. I'm just > shooting from the hip now, but maybe containing (cgroups?) untrusted > processes together into a set that could be frozen/idled so that runtime PM > would be more effective would be a workable solution? > > Anyways, that's enough rambling for now. I hope that sheds some light > on the concerns I have with suspend blockers. > > Kevin > > [1] http://embeddedlinuxconference.com/elc_2010/index.html -- 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/ |