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: Matthew Garrett on 3 May 2010 18:00 On Mon, May 03, 2010 at 09:40:26AM -0700, Kevin Hilman wrote: > 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.) I'd say that this is certainly the main issue, though the remaining periodic timers in the kernel are also inconvenient. > 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? I considered this. The problem is that not all of your wakeup events pass through trusted code. Assume we've used a freezer cgroup and the applications are now frozen. One of them is blocking on a network socket. A packet arrives and triggers a wakeup of the hardware. How do we unfreeze the userspace app? I agree that the runtime scenario is a far more appealing one from an aesthetic standpoint, but so far we don't have a very compelling argument for dealing with the starting and stopping of userspace. The use-cases that Google have provided are valid and they have an implementation that addresses them, and while we're unable to provide an alternative that provides the same level of functionality I think we're in a poor position to prevent this from going in. -- 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: Kevin Hilman on 3 May 2010 19:40 "Rafael J. Wysocki" <rjw(a)sisk.pl> writes: > On Monday 03 May 2010, Mark Brown wrote: >> On Mon, May 03, 2010 at 09:40:26AM -0700, Kevin Hilman wrote: >> >> > 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. >> >> The other concern here is that for many mobile systems the actual >> semantic intended by "suspend" as it's currently used is more runtime PM >> like than full suspend - the classic example of this is that when >> suspending while on a call in a phone you don't want to suspend the >> modem or audio CODEC, you want to leave them running. If you use a full >> system suspend then the drivers for affected components have to play >> guessing games (or add currently non-standard knobs for apps to twiddle) >> to decide if the system intends them to actually implement the suspend >> or not but with runtime PM it all falls out very naturally without any >> effort on the part of the driver. >> >> > 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. >> >> I fully agree with this. We do need to ensure that a runtime PM based >> system can suspend the CPU core and RAM as well as system suspend can >> but that seems doable. > > I _think_ it would be hard at least. On ACPI-based systems it's not doable at > all AFAICS. 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? > However, the real question is whether or not the opportunistic suspend feature > is worth adding to the kernel as such and I think it is. > > To me, it doesn't duplicate the runtime PM framework which is aimed at the power > management of individual devices rather than the system as a whole. From the use cases presented, the *usage* of suspend blockers is aimed at power management of individual devices or subsystems, just like usage of runtime PM. So I still see a large duplication in the usage and the goals of both frameworks. The goal of both is to always enter lowest-power state except - if there's activity (runtime PM for devices, CPUidle for CPU) - if there's a suspend blocker (opportunitic suspend) In addition, it will likely cause duplicate work to be done in drivers. Presumably, PM aware drivers will want to know if the system is in opportunistic mode. For example, for many drivers, doing runtime PM may not be worth the effort if the system is in opportunistic mode. 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. 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: Arve Hjønnevåg on 3 May 2010 20:10 On Mon, May 3, 2010 at 4:37 PM, Kevin Hilman <khilman(a)deeprootsystems.com> wrote: > "Rafael J. Wysocki" <rjw(a)sisk.pl> writes: > >> On Monday 03 May 2010, Mark Brown wrote: >>> On Mon, May 03, 2010 at 09:40:26AM -0700, Kevin Hilman wrote: >>> >>> > 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. >>> >>> The other concern here is that for many mobile systems the actual >>> semantic intended by "suspend" as it's currently used is more runtime PM >>> like than full suspend - the classic example of this is that when >>> suspending while on a call in a phone you don't want to suspend the >>> modem or audio CODEC, you want to leave them running. �If you use a full >>> system suspend then the drivers for affected components have to play >>> guessing games (or add currently non-standard knobs for apps to twiddle) >>> to decide if the system intends them to actually implement the suspend >>> or not but with runtime PM it all falls out very naturally without any >>> effort on the part of the driver. >>> >>> > 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. >>> >>> I fully agree with this. �We do need to ensure that a runtime PM based >>> system can suspend the CPU core and RAM as well as system suspend can >>> but that seems doable. >> >> I _think_ it would be hard at least. �On ACPI-based systems it's not doable at >> all AFAICS. > > 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? > I'm not that familiar with ACPI either, but I think the S-states entered by suspend are much lower power than the C-states entered by idle. >> However, the real question is whether or not the opportunistic suspend feature >> is worth adding to the kernel as such and I think it is. >> >> To me, it doesn't duplicate the runtime PM framework which is aimed at the power >> management of individual devices rather than the system as a whole. > > From the use cases presented, the *usage* of suspend blockers is aimed > at power management of individual devices or subsystems, just like > usage of runtime PM. > No, suspend blockers are mostly used to ensure wakeup events are not ignored, and to ensure tasks triggered by these wakeup events complete. > So I still see a large duplication in the usage and the goals of both > frameworks. �The goal of both is to always enter lowest-power state > except > > �- if there's activity (runtime PM for devices, CPUidle for CPU) > �- if there's a suspend blocker (opportunitic suspend) > > In addition, it will likely cause duplicate work to be done in > drivers. �Presumably, PM aware drivers will want to know if the system > is in opportunistic mode. �For example, for many drivers, doing > runtime PM may not be worth the effort if the system is in > opportunistic mode. Why? If a device is not in use it should be off regardless of what state the rest of the system is in. > > 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. > > Kevin > -- Arve Hj�nnev�g -- 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 3 May 2010 20:50 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. -- 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: Brian Swetland on 3 May 2010 20:50
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 >> >> In addition, it will likely cause duplicate work to be done in >> drivers. Presumably, PM aware drivers will want to know if the system >> is in opportunistic mode. For example, for many drivers, doing >> runtime PM may not be worth the effort if the system is in >> opportunistic mode. > > Why? If a device is not in use it should be off regardless of what > state the rest of the system is in. > >> 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. 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. 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. 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/ |