Re: A simple cpufreq(9)

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

On Fri, Sep 23, 2011 at 10:40:07PM +0300, Jukka Ruohonen wrote:
> On Fri, Sep 23, 2011 at 08:42:16PM +0200, Joerg Sonnenberger wrote:
> > On Fri, Sep 23, 2011 at 01:02:52PM +0300, Jukka Ruohonen wrote:
> > > [2] Note that even in the x86 land it is no longer necessarily known which
> > >     is the exact MHz at which the CPU currently runs (cf. TurboBoost, 
> > > etc.).
> > 
> > TurboBoost is a good reason for why "percent" is a bad measurement as
> > well. In fact, I find it more confusing. If a tool reports to the user
> > that NetBSD runs the CPU at 85% during a build.sh -j16, that's going to
> > result in surprising questions...
> 
> Well this is not really the case with TurboBoost; while there are few
> somewhat vague means to know the "turbo" in the kernel (not as a MHz
> though), this would show in the userland as 100 %, like it would show for
> the users of the MI functions.

Turbo Boost can be discovered and the highest state be marked as such.
With a plain percentage, you effectively take away the possibility to
detect if it is active or not.

> > Consider making the "unit" of scaling an additional attribute of the
> > list and provide userland with:
> > 
> > id, data, unit
> > 
> > as list, get/set is using the id.
> 
> I particularly wanted to avoid importing any lists to the MI kernel parts or
> to the userland. Using a percentage like done in OpenBSD would greatly
> simplify further uses in the kernel. But of course an unit of measurement
> (MHz, voltage, etc.) can be imported for heuristic purposes.

You can not avoid providing a list of available states. Such an
interface is inherently and completely broken.

> 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. Removing data because it is more "user friendly" kind
of misses the point that the kernel is not the UI. Whether it makes
sense for a specific implementation to provide a percentage question is
different. E.g. for an i7, you pretty much don't have a choice since EST
is lying on the low-level and it can be harder to reconstruct the
original value.

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

...and?

Joerg