Re: [PATCH] cpufreq: Governor poll frequency tuneables exported in config.

[Thomas Renninger]

On Monday 16 February 2009 14:33:54 Ãric Piel wrote:
> Mike Chan schreef:
> >     cpufreq: Governor poll frequency tuneables exported in config.
> >     
> Hello,
> 
> > +config CPU_FREQ_MIN_TICKS
> > +	int "Ticks between governor polling interval."
> > +	default 10
> > +	help
> > +	  Minimum number of ticks between polling interval for governors.
> I don't think it makes much sense to let anyone tune this parameter.
> This is a constant that says we need at least a 10% granularity to
> compute any statistic correctly. There is nothing much to be discussed
> or tuned.
> 
> 
> > +config CPU_FREQ_SAMPLING_LATENCY_MULTIPLIER
> > +	int "Sampling rate multiplier for governors."
> > +	default 1000
> > +	help
> > +	  Sampling latency rate multiplied by the cpu switch latency.
> > +	  Affects governor polling.
> This one, why not (although I don't think it's worth neither), and it
> would need a better documentation.
It is already configurable in userspace, no need to introduce a 
new config variable:

Documentation/cpu-freq/governors.txt

==================
sampling_rate: measured in uS (10^-6 seconds), this is how often you
want the kernel to look at the CPU usage and to make decisions on
what to do about the frequency.  Typically this is set to values of
around '10000' or more. It's default value is (cmp. with users-guide.txt):
transition_latency * 1000
The lowest value you can set is:
transition_latency * 100 or it may get restricted to a value where it
makes not sense for the kernel anymore to poll that often which depends
on your HZ config variable (HZ=1000: max=20000us, HZ=250: max=5000).
Be aware that transition latency is in ns and sampling_rate is in us, so 
you
get the same sysfs value by default.
Sampling rate should always get adjusted considering the transition latency
To set the sampling rate 750 times as high as the transition latency
in the bash (as said, 1000 is default), do:
echo `$(($(cat cpuinfo_transition_latency) * 750 / 1000)) \
    >ondemand/sampling_rate
===================

But this is only in the very latest cpufreq next tree and should pop up
in 2.6.30.

Hmm, the statement:
"Typically this is set to values of around '10000' or more"
Is wrong (E.g. if you have HZ=250 you cannot go below 80000), but I plan to 
touch this again soon. Then this statement hopefully is correct again.

    Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/