A single power preference knob

Power management under Linux is getting more complex as the kernel's capabilities grow. It is now possible to control power use through scheduling policies, idle state management, device states, and so on. Unfortunately, some power management choices have performance consequences; depending on the use to which the system is being put, those consequences may not be welcome. So there must be a way for system administrators to control how power management decisions are made.

Currently, that control is exercised through a number of individual system parameters. One controls whether the scheduler tries to coalesce processes onto a subset of the system's CPUs in the hope of letting others sleep. Another knob tells the idle governor which sleep states it is able to use. Yet another controls CPU frequency and voltage response. Simply knowing about all of the available parameters is hard; keeping them all tuned properly can be harder yet.

Len Brown has proposed the addition of an overall control parameter for power management, to be found in /sys/power/policy_preference. This knob would have five settings, ranging from "maximum performance at all times" to "save as much power as possible without actually turning the system off." With a control like this, system administrators could control system power policy without having to learn about all of the individual parameters involved; policy choices would also be applied to any new power-management parameters added in the future.

The idea was not universally loved, though. Some commenters asked for more than five settings, but Len argued that anybody needing more complex configurations should just continue to use the individual parameters. Others fear that the single policy might be interpreted differently by different drivers, leading to inconsistent results; they would rather see the continued use of individual parameters which exactly describe the desired behavior. The real discussion, though, cannot happen until some actual code has been posted, if and when that happens.

Index entries for this article
Kernel	Power management

---

to post comments

A single power preference knob

Posted Jun 24, 2010 8:17 UTC (Thu) by TRS-80 (guest, #1804) [Link] (10 responses)

This sounds like a job for a simple userspace program to me.

A single power preference knob

Posted Jun 24, 2010 8:48 UTC (Thu) by riteshsarraf (subscriber, #11138) [Link] (1 responses)

Currently, laptop-mode-tools does most of what has been proposed in the RFC.

What I did not see in the RFC is is whether the switch from one profile to another is going to be adaptive or event driven.

In laptop-mode-tools, we do this based on events. Currently, ON_BAT and ON_AC.

A single power preference knob

Posted Jun 24, 2010 12:49 UTC (Thu) by nescafe (subscriber, #45063) [Link]

Yeah, I pointed out in the thread that the knob he proposed does not really map to what most userspace programs that care about power management actually do.

A single power preference knob

Posted Jun 24, 2010 12:21 UTC (Thu) by kov (subscriber, #7423) [Link]

I had the same gut reaction.

A single power preference knob

Posted Jun 24, 2010 12:24 UTC (Thu) by NRArnot (subscriber, #3033) [Link] (1 responses)

Seconded. (+padding - LWN won't let me post a 9 byte comment)

9 byte comments not allowed you say?

Posted Jun 24, 2010 16:09 UTC (Thu) by ccurtis (guest, #49713) [Link]

I expect there's some very sound logic for such a restriction ...

Now, if only LWN had an optional "private reply" checkbox on the comment form...

A single power preference knob

Posted Jun 24, 2010 13:05 UTC (Thu) by Tobu (subscriber, #24111) [Link] (4 responses)

I agree that the kernel shouldn't contain complex policy, and should give ultimate control over policy to userland. But apparently the settings to tweak range wide and userland is missing some.

This master knob could provide a default value for settings that have yet to be tweaked by userland. When switching modes, the userland tweaks the master knob, then whatever knobs it is aware of. The problem with this is that most driver settings don't have an “unset, please fall back to the default” value. As a consequence, with the current proposal the default value can only be read by drivers that don't expose settings to userland yet. To be effective with existing, exposed settings, the master trigger would have to trigger changes to every one of them, and that's not something that should be done in-kernel.

Other solutions to the breadth of settings would be:

• an annotation mechanism that lists the knobs and a documentation tool that checks every knob appears in the Documentation directory;
• blessing one of the userland tools and requiring kernel drivers to update the tool as well;
• an introspection mechanism that lists the knobs, their range, and a default value for at least two power modes.

I like the introspection approach myself, since it will lead to better userland tools. Those tools should be able to discover and tweak settings they don't know about, and expose them to the user. It would also provide a good platform for experimenting with a watt meter.

A single power preference knob

Posted Jun 24, 2010 16:51 UTC (Thu) by nescafe (subscriber, #45063) [Link] (3 responses)

Introspection is of limited usability -- it is ultimately up to the end user or the distro to decide what level of power management makes sense for a given use case. I prefer the more complete documentation option.

A single power preference knob

Posted Jun 24, 2010 23:04 UTC (Thu) by hummassa (guest, #307) [Link] (1 responses)

I disagree strongly. I think this kind of parameters should be enumerable in a ALSA mixer like way.

A single power preference knob

Posted Jun 25, 2010 1:20 UTC (Fri) by nescafe (subscriber, #45063) [Link]

Enumerable is fine -- exposing them all in a /sys/power/powersave_knobs directory (or wherever) would be awesome. Once that is done, we can work on adding features that make it easier to introspect on them.

A single power preference knob

Posted Jun 25, 2010 0:12 UTC (Fri) by Tobu (subscriber, #24111) [Link]

Hopefully the userland can figure out a value from the introspection. If the knob exposes a range with two examples, a “powersave” value and a “balanced” value, the userland can pick the powersave value for powersave and more energy-efficient modes, and the balanced value for balanced and more performance-oriented modes. Generally: pick the example nearest the desired mode.

If you have a more advanced user willing to figure things out, you can let them view the range, pick values and submit a patch, but that doesn't need to be the default user experience.

A single power preference knob

Posted Jul 3, 2010 3:31 UTC (Sat) by abadidea (guest, #62082) [Link]

My thoughts are a) what happens if the admin changes one of the fine-tune knobs after setting this high-level knob, and hence b) shouldn't this be a userland script?