[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: A simple cpufreq(9)
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.
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
This is the case with ichlpcib(4) and piixpcib(4). Might be the
case on some embedded/exotic things as well.
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.
Main Index |
Thread Index |