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 4 May 2010 10:00 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. > Suspend blockers give us some flexibility on systems where runtime pm > will not get us all the way there. If you can meet your power needs > without needing suspend blockers, awesome, you don't need them on that > platform. The patchset Arve sent out makes this feature an > off-by-default kernel configuration option that compiles out to no-ops > when disabled. I think a big part of this for me is that this approach changes the intended use of the system-wide suspend a bit, complicating it a bit further than it already is. We end up doing a suspend (which in the normal course of affairs means that the driver should shut everything down) partly as a substitute for runtime PM on the core system devices and partly because our runtime PM isn't doing as well as it should on the individual devices. 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. > In our experience, periodic timers and polling, both userspace side > and kernelside make suspend blockers a win even on platforms like OMAP > which have pretty flexible hardware power management. Going to low > power states in idle results in higher average power consumption than > going to the same states in full suspend, at least on Android devices > shipping today. There's definite work to be done here, yes. -- 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 4 May 2010 10:00 On Tue, 4 May 2010, Matthew Garrett wrote: > On Mon, May 03, 2010 at 04:37:22PM -0700, Kevin Hilman wrote: > > > Please forgive the ignorance of ACPI (in embedded, we thankfully live > > in magical world without ACPI) but doesn't that already happen with > > CPUidle and C-states? I think of CPUidle as basically runtime PM for > > the CPU. IOW, runtime PM manages the devices, CPUidle manages the CPU > > (via C-states), resulting in dynaimc PM for the entire system. What > > am I missing? > > ACPI doesn't provide any functionality for cutting power to most devices > other than shifting into full system suspend. The number of wakeup > events available to us on a given machine is usually small and the > wakeup latency large, so it's not terribly practical to do this > transparently on most hardware. Another thing that Kevin is missing: There is more to the system than the devices and the CPU. For example: RAM, an embedded controller (on modern desktop/laptop systems), a power supply, and so on. Dynamic PM for the CPU and the devices won't power-down these things, but system PM will. 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: Mark Brown on 4 May 2010 11:00 On Tue, May 04, 2010 at 09:51:39AM -0400, Alan Stern wrote: > On Tue, 4 May 2010, Matthew Garrett wrote: > > On Mon, May 03, 2010 at 04:37:22PM -0700, Kevin Hilman wrote: > > > Please forgive the ignorance of ACPI (in embedded, we thankfully live > > > in magical world without ACPI) but doesn't that already happen with > > > CPUidle and C-states? I think of CPUidle as basically runtime PM for > > > the CPU. IOW, runtime PM manages the devices, CPUidle manages the CPU > > > (via C-states), resulting in dynaimc PM for the entire system. What > > > am I missing? > > ACPI doesn't provide any functionality for cutting power to most devices > > other than shifting into full system suspend. The number of wakeup > > events available to us on a given machine is usually small and the > > wakeup latency large, so it's not terribly practical to do this > > transparently on most hardware. > Another thing that Kevin is missing: There is more to the system than > the devices and the CPU. For example: RAM, an embedded controller (on > modern desktop/laptop systems), a power supply, and so on. Dynamic PM > for the CPU and the devices won't power-down these things, but system > PM will. In an embedded system I'd expect that these other system devices would fall naturally out through the management of the CPUs and devices - for example, the drivers for the individual devices could use the regulator API to manage their supplies and runtime PM is being used to manage CPU core stuff - or could at least readily be handled in a similar fashion. This isn't to say that we're there yet from an implementation point of view, of course. -- 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 11:20 Matthew Garrett <mjg(a)redhat.com> writes: > On Mon, May 03, 2010 at 04:37:22PM -0700, Kevin Hilman wrote: > >> Please forgive the ignorance of ACPI (in embedded, we thankfully live >> in magical world without ACPI) but doesn't that already happen with >> CPUidle and C-states? I think of CPUidle as basically runtime PM for >> the CPU. IOW, runtime PM manages the devices, CPUidle manages the CPU >> (via C-states), resulting in dynaimc PM for the entire system. What >> am I missing? > > ACPI doesn't provide any functionality for cutting power to most > devices other than shifting into full system suspend. The number of > wakeup events available to us on a given machine is usually small > and the wakeup latency large, so it's not terribly practical to do > this transparently on most hardware. OK, that's a major difference with embedded SoCs where the kernel must directly manage the power state of all devices using runtime PM. So basically, on ACPI systems, runtime PM doesn't get you any power savings for most devices. 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: Matthew Garrett on 4 May 2010 11:30
On Tue, May 04, 2010 at 08:13:09AM -0700, Kevin Hilman wrote: > So basically, on ACPI systems, runtime PM doesn't get you any power > savings for most devices. I'd say it does for most devices, but the power savings may not be as great as they would be with fine-grained control over power rails. -- 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/ |