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.
