Re: A simple cpufreq(9)

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

On Sat, Sep 24, 2011 at 07:20:16AM +0200, Joerg Sonnenberger wrote:
> You can not avoid providing a list of available states. Such an
> interface is inherently and completely broken.

Heh, right. Why?

> > Nor do I see any real difference whether an user sets the CPU frequency to
> > "{ 16 %, 35 %, 100 % } MHz" or to "{ 821, 922, 1657 } MHz", expect that the
> > former is clearer and more user friendly.
> 
> Sorry, it is not.

So you propose sailing to the dark waters of sysmon_envsys(9)? You need to
export integers (e.g. MHz), booleans (on/off), triplets (low/medium/high),
and so on, all depending on the machine and/or platform.

> Removing data because it is more "user friendly" kind of misses the point
> that the kernel is not the UI.

The exported data is not reliable. On x86 it is typically rounded and
approximated by the BIOS writers.

> > Note also that for instance some ARM systems may use very fine grained 
> > lists.
> 
> ...and?

Try to think beyond cpuctl(8). This should be done so that there is a
*simple* MI interface that can be extended in the future.

If you want a MI interface, the first thing is to agree upon a common scale.
Frequency scaling is a step function, so you could start from

        1. { LOW, HIGH } or { DISABLED, ENABLED }.

Maybe you could then proceed with

        2. { LOW, MEDIUM, HIGH }
or
           { 800 MHz, 1200 MHz, 1600 MHz }.

But how about

        3. { 800 MHz, 805 MHz, 810 MHz, 815 MHz, 820 MHz, 1300 MHz, 1800 MHz }?

        4. And how about some ARM system that may export over 30 states,
           possibly with non-uniform intervals?

Can outline a consistent algorithm for an user-space or in-kernel governor
to choose a state from these four examples?

As such, a percentage here is nothing more than a scale from zero to
hundred. It would be the responsibility of the MD implementation to
interpolate this to whatever scale it may be using.

But of course it is inherently and completely broken.

- Jukka.