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: Rafael J. Wysocki on 4 May 2010 16:50 On Tuesday 04 May 2010, Rafael J. Wysocki wrote: > On Tuesday 04 May 2010, Kevin Hilman wrote: > > Mark Brown <broonie(a)opensource.wolfsonmicro.com> writes: > > > > > On Mon, May 03, 2010 at 05:43:34PM -0700, Brian Swetland wrote: > > >> On Mon, May 3, 2010 at 5:09 PM, Arve Hj�nnev�g <arve(a)android.com> wrote: > > >> > On Mon, May 3, 2010 at 4:37 PM, Kevin Hilman > > > > > >> >> This last point is especially troubling. I don't find it a comforting > > >> >> path to go down if the drivers have to start caring about which PM > > >> >> policy is currently in use. > > > > > >> I'll echo Arve here -- all drivers should seek to be in the lowest > > >> power state possible at all times. We've never suggested that > > >> suspend_block is a substitute for that. > > > > > > Looking at this from a subsystem/driver author point of view the problem > > > I'm faced with is that as a result of using system suspend much more > > > aggressively the subsystem and driver layers are getting conflicting > > > instructions about what the lowest power state possible is. > > > > Exactly. > > > > With runtime PM, there is flexibility in choosing the lowest power > > state at the device/subsystem level, based on activity, timeouts, > > bitrate, dependencies, latency/throughput constraints, etc. > > > > With opportunistic suspend, all of this flexibility is gone, and the > > device/subsystem is told to go into the lowest power, highest latency > > state, period. > > Guys, please. > > The opportunistic suspend feature is _not_ to replace runtime PM by any means! > > However, there are situations in which runtime PM is clearly insufficient. > The idea behind runtime PM is that subsystems and device drivers will know > when to put devices into low power states and save energy this way. Still, > even if all subsystems do that 100% efficiently, there may be more savings > possible by putting the entire system into a sleep state (like on ACPI-based > PCs) and we can reach there by runtime PM alone. s/can/can't/; s/reach/go/ 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: Kevin Hilman on 4 May 2010 19:30 "Rafael J. Wysocki" <rjw(a)sisk.pl> writes: > On Tuesday 04 May 2010, Mark Brown wrote: >> On Tue, May 04, 2010 at 11:06:39AM -0700, Kevin Hilman wrote: >> >> > With opportunistic suspend, all of this flexibility is gone, and the >> > device/subsystem is told to go into the lowest power, highest latency >> > state, period. >> >> Well, half the problem I have is that unfortunately it's not a case of >> doing that period. The prime example I'm familiar with is that for >> understandable reasons users become irate when you power down the audio >> CODEC while they're in the middle of a call so if opportunistic PM is in >> use then the audio subsystem needs some additional help interpreting a >> suspend request so that it can figure out how to handle it. Similar >> issues apply to PMICs, though less pressingly for various reasons. >> >> Just to be clear, I do understand and mostly agree with the idea that >> opportunistic suspend presents a reasonable workaround for our current >> inability to deliver good power savings with runtime PM methods on many >> important platforms but I do think that if we're going to make this >> standard Linux PM functionality then we need to be clearer about how >> everything is intended to hang together. > > At the moment the rule of thumb is: if you don't need the opportunistic > suspend, don't use it. It is not going to be enabled by default on anything > other than Android right now. Sure, but there are driver authors and subsystem maintainers who care about optimal PM in "normal" Linux *and* in Android. As a PM maintainer for an embedded platform (OMAP) used in both, I certainly care about both, so "disable it if you don't like it" is not really an option. IMO, driver/subsystem authors should not have to care if the userspace is Android or not. We should be working towards a world where Android is not a special case. 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 4 May 2010 19:50 On Wednesday 05 May 2010, Kevin Hilman wrote: > "Rafael J. Wysocki" <rjw(a)sisk.pl> writes: > > > On Tuesday 04 May 2010, Mark Brown wrote: > >> On Tue, May 04, 2010 at 11:06:39AM -0700, Kevin Hilman wrote: > >> > >> > With opportunistic suspend, all of this flexibility is gone, and the > >> > device/subsystem is told to go into the lowest power, highest latency > >> > state, period. > >> > >> Well, half the problem I have is that unfortunately it's not a case of > >> doing that period. The prime example I'm familiar with is that for > >> understandable reasons users become irate when you power down the audio > >> CODEC while they're in the middle of a call so if opportunistic PM is in > >> use then the audio subsystem needs some additional help interpreting a > >> suspend request so that it can figure out how to handle it. Similar > >> issues apply to PMICs, though less pressingly for various reasons. > >> > >> Just to be clear, I do understand and mostly agree with the idea that > >> opportunistic suspend presents a reasonable workaround for our current > >> inability to deliver good power savings with runtime PM methods on many > >> important platforms but I do think that if we're going to make this > >> standard Linux PM functionality then we need to be clearer about how > >> everything is intended to hang together. > > > > At the moment the rule of thumb is: if you don't need the opportunistic > > suspend, don't use it. It is not going to be enabled by default on anything > > other than Android right now. > > Sure, but there are driver authors and subsystem maintainers who care > about optimal PM in "normal" Linux *and* in Android. > > As a PM maintainer for an embedded platform (OMAP) used in both, I > certainly care about both, so "disable it if you don't like it" is not > really an option. > > IMO, driver/subsystem authors should not have to care if the userspace > is Android or not. We should be working towards a world where Android > is not a special case. I agree, but "working on towards a world where ..." need not mean "be there from day one" IMO. Also, I guess you'll agree that using the same _binary_ kernel with Android and non-Android user spaces doesn't necessarily make sense (regardless of the fact that Android kernels have hardware-specific board files included), so probably you'll still disable opportunistic suspend building the kernel for non-Android systems (at least for the time being). It looks like you're thinking the opportunistic suspend somehow is (or can be used as) a replacement for runtime PM, but this is not the case. The reason why it's not the case is that runtime PM works with the assumption that user space is not frozen and it works on individual devices. OTOH, generally, there is a limit on the amount of energy savings you can achieve with runtime PM alone and something like the opportunistic suspend is necessary to go beyond that limit. Now, I can easily imagine using suspend blockers and runtime PM in the same driver with the general rule that you'll probably want to call suspend_unblock() whenever the device is suspended with the help of the runtime PM framework. That really depends on the device and the driver in question, 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 4 May 2010 20:00 On Tue, May 04, 2010 at 10:23:41PM +0200, Rafael J. Wysocki wrote: > On Tuesday 04 May 2010, Kevin Hilman wrote: > > Mark Brown <broonie(a)opensource.wolfsonmicro.com> writes: > Guys, please. > The opportunistic suspend feature is _not_ to replace runtime PM by any means! Certainly in my case and I think Kevin's I agree with the need for the bodge at the minute if we can get a clearer idea of how it's supposed to work. > when to put devices into low power states and save energy this way. Still, > even if all subsystems do that 100% efficiently, there may be more savings > possible by putting the entire system into a sleep state (like on ACPI-based > PCs) and we can reach there by runtime PM alone. Right, this is likely to be a win for PCs - for embedded systems we rarely have other software to interoperate with so if you can make the hardware do it then it's unlikely there would be any fundamental issue with Linux doing it at runtime. > > > I'd be a lot more comfortable with this if it came with a mechanism for > > > communicating the intended effect of a suspend on a per-device level so > > > that the drivers have a clear way of figuring out what to do when the > > > system suspends. If there isn't one we can add subsystem or driver > > > specific hooks, of course, but it'd be better to address this at the > > > system level. > > I agree. > I'm not sure. Why _exactly_ would you need that? The use case that causes serious issues with this at the minute in the domains I work is this: On a mobile phone when the system is in a voice call the data flow for the call is entirely handled outside the CPU (normally referred to as Applications Processor or AP here) by the baseband and audio CODEC, which are either integrated or directly connected by analogue or digital audio links on the board. If the user has the phone to their ear and is talking away with the screen blanked then the AP is just waiting for input, will appear idle and so trigger an opportunistic suspend. If the audio CODEC is managed by Linux (as is standard) then running through the suspend process will as things stand cause the audio subsystem to be suspended. Since in the normal course of affairs suspend means power down that's what will happen, but this is clearly highly undesirable in this situation. Now, the solution here if we're going to use opportunistic suspend like this is to provide some method for the audio subsystem to figure out that the system doesn't actually want it to suspend when it gets told do do so. Like I say ideally we'd provide some standard interface in the PM subsystem for userspace to communicate this to subsystems and drivers so that we've got a joined up story when people run into issues in cases like this, though obviously if this goes in then we'll have to put in something subsystem or driver specific for affected areas. I know what I'd implement generically for audio, but I've held back since the option is fairly messy when not used in conjunction with a deliberate choice to use opportunistic suspend and I was expecting a standard mechanism to slot into to provide control for userspace. In other words, the issue is that we run into situations where we need an element of suspend control to go along with the opportunistic suspend in order to allow some elements to be kept running - since suspend blocking is taken suspend suppression seems like a reasonable term. -- 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 4 May 2010 20:30
On Wednesday 05 May 2010, Mark Brown wrote: > On Tue, May 04, 2010 at 10:23:41PM +0200, Rafael J. Wysocki wrote: > > On Tuesday 04 May 2010, Kevin Hilman wrote: > > > Mark Brown <broonie(a)opensource.wolfsonmicro.com> writes: > > > Guys, please. > > > The opportunistic suspend feature is _not_ to replace runtime PM by any means! > > Certainly in my case and I think Kevin's I agree with the need for the > bodge at the minute if we can get a clearer idea of how it's supposed to > work. > > > when to put devices into low power states and save energy this way. Still, > > even if all subsystems do that 100% efficiently, there may be more savings > > possible by putting the entire system into a sleep state (like on ACPI-based > > PCs) and we can reach there by runtime PM alone. > > Right, this is likely to be a win for PCs - for embedded systems we > rarely have other software to interoperate with so if you can make the > hardware do it then it's unlikely there would be any fundamental issue > with Linux doing it at runtime. Evidently, the Android developers had a problem with that. Of course, you can argue that they didn't consider using runtime PM for this purpose, but the real question is how much time it would take to achieve the same level of energy saving using runtime PM without opportunistic suspend. > > > > I'd be a lot more comfortable with this if it came with a mechanism for > > > > communicating the intended effect of a suspend on a per-device level so > > > > that the drivers have a clear way of figuring out what to do when the > > > > system suspends. If there isn't one we can add subsystem or driver > > > > specific hooks, of course, but it'd be better to address this at the > > > > system level. > > > > I agree. > > > I'm not sure. Why _exactly_ would you need that? > > The use case that causes serious issues with this at the minute in the > domains I work is this: > > On a mobile phone when the system is in a voice call the data flow for > the call is entirely handled outside the CPU (normally referred to as > Applications Processor or AP here) by the baseband and audio CODEC, > which are either integrated or directly connected by analogue or digital > audio links on the board. If the user has the phone to their ear and is > talking away with the screen blanked then the AP is just waiting for > input, will appear idle and so trigger an opportunistic suspend. If the > audio CODEC is managed by Linux (as is standard) then running through > the suspend process will as things stand cause the audio subsystem to be > suspended. Since in the normal course of affairs suspend means power > down that's what will happen, but this is clearly highly undesirable in > this situation. In that case someone (either a driver or, most likely, user space) will need to keep a suspend blocker active. > Now, the solution here if we're going to use opportunistic suspend like > this is to provide some method for the audio subsystem to figure out > that the system doesn't actually want it to suspend when it gets told do > do so. Like I say ideally we'd provide some standard interface in the > PM subsystem for userspace to communicate this to subsystems and drivers > so that we've got a joined up story when people run into issues in cases > like this, though obviously if this goes in then we'll have to put in > something subsystem or driver specific for affected areas. My understanding is that on Android suspend blockers are used for this purpose. > I know what I'd implement generically for audio, but I've held back since > the option is fairly messy when not used in conjunction with a deliberate > choice to use opportunistic suspend and I was expecting a standard mechanism > to slot into to provide control for userspace. > > In other words, the issue is that we run into situations where we need > an element of suspend control to go along with the opportunistic suspend > in order to allow some elements to be kept running - since suspend > blocking is taken suspend suppression seems like a reasonable term. Suspend really is a sledgehammer thing. Either you suspend the whole system or you don't suspend at all. You can prevent opportunistic suspend from happening using suspend blockers (that's what they are for), but that's pretty much everything you can do about it. If you want power savings while some parts of the system are active, use runtime PM for that. What I'd use opportunistic suspend for is not the saving of energy when there's a call in progress, because in that case some parts of the system need to be active, but to save energy when the device is completely idle, ie. the user interface is not used, music is not played "in the background" etc. (my phone is in such a state 90% of the time at least). 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/ |