Re: A simple cpufreq(9)

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Sat, Sep 24, 2011 at 08:41:10PM +0300, Jukka Ruohonen wrote:
> 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.

It's not relevant what the exact clock rate is. It's an approximation.
Just like the TSC frequency won't be measured the same on every boot.

Ignoring intermediate values can be literally a lot of unwanted noise.
On my old laptop, I couldn't play all medium quality H.264 streams at
smallest CPU frequency. It worked with some of the intermediate levels
and those create enough heat less, that it makes a difference in terms
of fan activity. My point is that not every load is switches between
idle and 100%.

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

Old speed step has only two settings -- slow and fast. Presenting that
as boolean toogle is fine.

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

Depending on the actual implementation, you might not have a choice. I
expect that to happen a lot in the embedded world, e.g. for SoCs. Given
that they often require a lot of customisation in first place, it
doesn't really change something.

>       2. Power per state.
> 
>          In majority of cases this is entirely unknown, and if coming from
>          the BIOS, too unreliable.

I was listening possible decision making factors. Depending on your
environment, you have all or none of them. The main point is that good
decision making needs more than just "You can toogle this".

Joerg