From: Matthew Garrett on
On Tue, May 04, 2010 at 09:51:39AM -0400, Alan Stern wrote:

> 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.

Somewhat true - machines with C1E support will put the RAM into self
refresh when the cpu is idle, but you're right that there are various
components that we simply don't have control over in the desktop world
at present.

--
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
Arve Hj�nnev�g <arve(a)android.com> writes:

> On Mon, May 3, 2010 at 4:37 PM, Kevin Hilman
> <khilman(a)deeprootsystems.com> wrote:
>> "Rafael J. Wysocki" <rjw(a)sisk.pl> writes:
>>

[...]

>>> 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.

OK, but my point was that their *usage* is at the level of inidividual
devices and subsystems, just like runtime PM. Hence, duplicate work.

>> 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.

Not necessarily.

If a device is not in use, what power state it goes into depends on
many device/subsystem specific things. For example, recent activity
(timeouts), whether it will be busy soon (pending transfers),
latency/throughput constraints, dependency on other devices, or any
other device/subsystem specific reason.

All of these can be handled with runtime PM. None of which are taken
into consideration with opportunistic suspend.

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
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.
--
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
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.

> >> 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.
>
> Agreed, and because of this, part of my concern is that opportunistic
> suspend will take the place of doing the "right thing" which (IMHO)
> would be to improve runtime PM for devices.

It really can't, at least on some platforms. For example, resuming a PC
notebook from suspend to RAM takes more than 1s (with an SSD; rotational disks
add more latency here) which is way too much for such a replacement.

Besides, there also is room for runtime PM in the Android framework, because
it needs to suspend certain devices without freezing processes, for example.

The freezing of processes is the most important difference to me. Runtime PM
works with the assumption that processes are not frozen (hence the name), but
arguably energy savings you can get without going behind that point are
naturally limited.

> > 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?

> I think there needs to be more discussion on the indended usage
> of suspend blockers by drivers/subsystems, especially those PM aware
> drivers and subsystems already doing runtime PM with constraints etc.
>
> >> 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.
>
> And I've admitted this to be the only compelling reason for
> opportunistic suspend so far.
>
> But the driver/subsystem implications of opportunistic suspend still
> need some fleshing out IMO.

At the moment, if you're not on Android, there are none.

Thanks,
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
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.

However, since Android is a legitimate user of the Linux kernel, I see no
reason to reject this feature right away. There are many kernel features
that aren't used by all platforms.

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/