Re: A simple cpufreq(9)

[Jukka Ruohonen <jruohonen%iki.fi@localhost>]

On Fri, Sep 30, 2011 at 11:27:46AM -0500, David Young wrote:
> I don't think that the division of responsibility for power management
> between kernel & userland is obvious.

It may not be, but the arguments against kernel-level implementation are
largely practical. There is no one size fits all. The kernel can not decide
when the screen is too dark to read or what the battery level should be.
In short: I think there are too many variables to do it in the kernel.

I think almost a consensus was reached about making a rc.conf(5)-like
configuration file for powerd(8):

        http://mail-index.netbsd.org/tech-userlevel/2011/05/06/msg005009.html

Some imaginary examples:

        suspend_lid="YES"                   # Suspend when the lid is closed
        suspend_button="YES"                # Activate suspend-button
        
        battery_backlight="90"              # Backlight (%) when AC is off
        battery_stop_daemons="bluetooth"    # Daemons to stop when AC is off

None of these really belong to the kernel.

> How do you hope for cpufreq(9) to be used?

I have a patch ready that transforms the existing MD implementations to use
it, so at first iteration, it will provide a consistent user interface via
cpuctl(8). Later, different "governors" can be implemented.

> While reading the API and discussion, it occurred to me that if
> cpufreq(9) is chiefly used for making power/performance trade-offs,
> maybe the API should be concerned with the goal (power savings) instead
> of an independent variable (frequency).

I think it is more about utilizing "increase()" and "decrease()" functions
in well chosen sections of kernel code. Or rather, pass them via a governor
that does the selection whether it is plausible to "frequency--".

> Then maybe you can use one API---cpupm(9)?---to set the objective, and let
> the implementation choose the variables (C-state, P-state, frequency) to
> tweak.

Obviously each one may exist regardless of the other. For instance, currently
in NetBSD only P-states are (or can be) used. There are no "C-states" in
arch/macppc. Generally, for practical reasons, I'd vote for a "bottom-up"
approach here. If someone later realizes that all this fits to a perfect
single API, I am all for it.

But to read between the lines, I think you are approaching what could be
called "power management quality of services". Shameless Linux-plug again,
but the slides are worth a look:

        http://elinux.org/images/f/f9/Elc2008_pm_qos_slides.pdf

- Jukka.

PS. P-states == frequency.