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: Kevin Hilman on 5 May 2010 19:10 Alan Stern <stern(a)rowland.harvard.edu> writes: > 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. I guess what we're talking about here is a set of per-device constraints that could be used by both [opportunistic|system] suspend and runtime PM. For lack of a better term, per-device PM QoS (as compared to the current system-wide PM QoS.) For example, if userspace (or some other device) has communicated that it has a constraint on the audio HW, then both the suspend path and the runtime PM path could check those constraints before making a decision on how to act. Hopefully the phone app would set a constraint and the cow-noise app would not. :) On OMAP, we keep track of per-device constraints (currently latency and throughput) in order to make proper run-time PM decicions in the kernel, but we are realizing that we need a way for userspace to communicate these constraints as well, so that userspace can make power vs. performance policy decisions instead of the kernel. Probably generalizing these into the LDM is the direction to go so userspace can set constraints on a per-device (or per-class?) basis: /sys/devices/.../power/constraint/throughput /sys/devices/.../power/constraint/wakeup_latency /sys/devices/.../power/constraint/... ? 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: Mark Brown on 5 May 2010 19:10 On Thu, May 06, 2010 at 12:05:01AM +0200, Rafael J. Wysocki wrote: > So, gnerenally, we may need a mechanism to specify which components of the > system need to stay powered while the whole system is suspended (in addition to > wakeup devices, that is). > That certainly I can agree with. > I'm not sure, however, in what way this is relevant to the $subject patchset. The patch set essentially makes using a full system suspend as the lowest power state for runtime PM part of the standard Linux power management toolkit which means that it's no longer clear as it used to be that suspend is an instruction to cease all activity and go into a minimal power state if the device is not a wake source. In the primary existing application this change interoperates very poorly with at least the current audio subsystem since that handles suspend by ceasing all activity and powering as much as it can off, which is sensible for manual only suspends but highly undesirable for opportunistic suspend in phones. We should therefore have some idea how this and any other affected areas are supposed to work. As I said in my reply to Ted earlier I think we may actually be converging on not worrying too much about it at the global level and doing subsystem specific things to discover and handle affected cases, at least for the time being. Ideally we'd have something standard to hook into but no subsystems apart from audio have actually been identified as being affected so it's not clear to me that a general solution is going to be worth the effort, if there's no actual users it may just confuse people by adding yet more power managment stuff to learn. -- 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 19:20 On Thursday 06 May 2010, Kevin Hilman wrote: > Alan Stern <stern(a)rowland.harvard.edu> writes: > > > 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. > > I guess what we're talking about here is a set of per-device > constraints that could be used by both [opportunistic|system] suspend > and runtime PM. For lack of a better term, per-device PM QoS (as > compared to the current system-wide PM QoS.) > > For example, if userspace (or some other device) has communicated that > it has a constraint on the audio HW, then both the suspend path and the > runtime PM path could check those constraints before making a decision > on how to act. Hopefully the phone app would set a constraint and the > cow-noise app would not. :) > > On OMAP, we keep track of per-device constraints (currently latency > and throughput) in order to make proper run-time PM decicions in the > kernel, but we are realizing that we need a way for userspace to > communicate these constraints as well, so that userspace can make > power vs. performance policy decisions instead of the kernel. > > Probably generalizing these into the LDM is the direction to go so > userspace can set constraints on a per-device (or per-class?) basis: > > /sys/devices/.../power/constraint/throughput > /sys/devices/.../power/constraint/wakeup_latency > /sys/devices/.../power/constraint/... ? That sounds reasonable although it may be a challenge to find a set of universal constraints common to all devices. 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: Rafael J. Wysocki on 5 May 2010 19:40 On Thursday 06 May 2010, Mark Brown wrote: > On Thu, May 06, 2010 at 12:05:01AM +0200, Rafael J. Wysocki wrote: > > > So, gnerenally, we may need a mechanism to specify which components of the > > system need to stay powered while the whole system is suspended (in addition to > > wakeup devices, that is). > > > That certainly I can agree with. > > > I'm not sure, however, in what way this is relevant to the $subject patchset. > > The patch set essentially makes using a full system suspend as the > lowest power state for runtime PM part of the standard Linux power > management toolkit which means that it's no longer clear as it used to > be that suspend is an instruction to cease all activity and go into a > minimal power state if the device is not a wake source. I don't see why, really. This patchset doesn't change the meaning of suspend at all, it only changes the way in which suspend is triggered (if specifically set up that way). Even without the patchset you may implement a power manager in user space that will suspend the system whenever it thinks it's idle. > In the primary existing application this change interoperates very poorly > with at least the current audio subsystem since that handles suspend by > ceasing all activity and powering as much as it can off, which is sensible for > manual only suspends but highly undesirable for opportunistic suspend in > phones. You said that there's no fundamental difference between manual and opportunistic suspend. It only matters what _you_ are going to use suspend for. I agree that at the moment it's not suitable for aggressive power management in phones because of the audio problem, but that applies to "manual" as well as to "opportunistic" suspend. You're saying that suspend is not suitable for one particular purpose in its current form, which is entirely correct, but that doesn't imply that the patchset is wrong. 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: Brian Swetland on 5 May 2010 19:50
On Wed, May 5, 2010 at 4:03 PM, Kevin Hilman <khilman(a)deeprootsystems.com> wrote: > > I guess what we're talking about here is a set of per-device > constraints that could be used by both [opportunistic|system] suspend > and runtime PM. For lack of a better term, per-device PM QoS (as > compared to the current system-wide PM QoS.) > > For example, if userspace (or some other device) has communicated that > it has a constraint on the audio HW, then both the suspend path and the > runtime PM path could check those constraints before making a decision > on how to act. Hopefully the phone app would set a constraint and the > cow-noise app would not. :) > > On OMAP, we keep track of per-device constraints (currently latency > and throughput) in order to make proper run-time PM decicions in the > kernel, but we are realizing that we need a way for userspace to > communicate these constraints as well, so that userspace can make > power vs. performance policy decisions instead of the kernel. > > Probably generalizing these into the LDM is the direction to go so > userspace can set constraints on a per-device (or per-class?) basis: > > /sys/devices/.../power/constraint/throughput > /sys/devices/.../power/constraint/wakeup_latency > /sys/devices/.../power/constraint/... ? The constraint stuff is definitely something I'd love to talk about in detail. It's a problem that I think is common to every SoC I've worked with. Having a general solution for this problem (of specifying and observing various constraints for clock, power, qos, etc) kernel-wide would seem like a big win. Might be worth kicking some design ideas around and getting a bunch of the interested parties together at some of the upcoming linux conference things this fall on the east coast? Brian -- 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/ |