lkml.org 
[lkml]   [2010]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [linux-pm] RFC: /sys/power/policy_preference
From
On Fri, Jun 18, 2010 at 12:56 AM, Len Brown <lenb@kernel.org> wrote:
> On Thu, 17 Jun 2010, Victor Lowther wrote:
>
>> > The idea here is to not require user-space to need updating
>> > whenever a future knob is invented.  We can do a great job
>> > at documenting the past, but a poor job of documenting the future:-)
>>
>> Well, I would suggest that the habit of not documenting what is
>> happening with power management in the kernel needs to change, then.
>
> Actually some of the knobs I showed in the examples
> have been documented for *years*, yet are ignored
> by user-space today.  I don't want to insult user-space
> programmers, but the reality is that simpler is usually better.

Let me explain where I am coming from, then. I maintain pm-utils, one
of the main low-level bodies of userspace code that concerns itself
with power management. I am currently in the process of standardizing
some of the more common power management tweaks so that they will work
in a cross distro manner, and know from this that the documentation we
have is badly fragmented -- if you know exactly what you are looking
for, you can google or grep for it, but if you do not, there is no
easy way to find a list of all the power management settings you can
tune.

>> Having the documentation and example code for how to tweak the various
>> power management settings from userspace is inherently more flexible
>> than trying to expose a single knob from the kernel to userspace for
>> power management, with little loss of flexibility.
>
> Yes, the ultimate in flexibility is to update user-space whenever
> some new driver or new knob appears in the kernel.  I'm not proposing
> that ability be taken away.  I'm proposing that in many cases it
> is unnecessary.

I disagree. Most of userspace does not care about how the system is
trying to save power. I maintain one that does, and I do not like the
idea of adding another knob whose entire purpose is to map other,
already existing knobs onto a line, especially when we can do that in
userspace easily enough if anyone actually wants it.

> The idea is to have the ability to add something to the
> kernel and avoid the need to make any change to user-space.

Userspace in this case consists mainly of
acpi-scripts/pm-utils/laptop-mode-tools, upower,
g-p-m/kpowersave/x-p-m, and X. I can only speak for pm-utils, but the
model pm-utils, acpi-scripts, and laptop-mode-tools use does not map
to your proposed knob at all. We use a two-state model -- either we
are on AC power and use the kernel's default power state, or we are on
battery power and set power management to a set of distro or user
chosen set of parameters. I am working on making pm-utils contain
some predefined powersaving policies, but I do not expect them to
change the two-state model much more than changing which power
management tweaks are used in the on-ac and on-battery states.

> thanks,
> -Len Brown, Intel Open Source Technology Center
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2010-06-18 13:57    [W:0.063 / U:0.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site