Re: A simple cpufreq(9)

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

On Sat, Sep 24, 2011 at 10:14:13AM +0200, Joerg Sonnenberger wrote:
> For the in-kernel use it should be completely irrelevant what the
> property is. Any automatic mechanism should only care about the
> associated properties (latency, reduction in power consumption etc). I
> don't see any of that addressed at this point either.

So let's look at this from a different POV.

Here is a datasheet for the reliable information:

        1. Maximum and minimum (or on/off).

        2. Idle times, etc. (MI stuff).

        3. Transition latency (easily simulated).

Here is a datasheet for unreliable and unknown data:

        1. Actual clock rate.

           Unreliable.

           We all know what est(4) and powernow(4) are like; no policy
           should rely on any intermediate values that comes out of these
           two. As usual, with ACPI there are a lot of known bugs about
           incorrect values.

           Unknown.

           This is the case with ichlpcib(4) and piixpcib(4). Might be the
           case on some embedded/exotic things as well.

           Maintenance.

           If the information is available from a datasheet, requires
           tabulation for each CPU model.

        2. Power per state.

           In majority of cases this is entirely unknown, and if coming from
           the BIOS, too unreliable.

I am quite familiar with the Linux cpufreq subsystem and I am not convinced
at all that we want something like that. I vote for a simple on/off boolean.

- Jukka.