cpufreq_conservative units weirdness
PATCH 1/2 cpufreq_conservative units weirdness
Hi there,
I've recently been looking through the cpufreq_conservative driver (mainly because I thought that it was adapting awfully slowly to the changes in my load. It seems to me that there is some confusion regarding the units of transition_latency (in nS) and the sampling_rate (in uS).
At least the comments don't seem to match my understanding of what the code is doing. I have always used the term "sampling rate" to describe a frequency, i.e. higher sampling rate means more samples per second. The way it is used in the code, sampling_rate describes a sampling interval, i.e. higher sampling_rate means fewer samples.
This first patch is supposed to change the comments to describe, what is actually going on.
------
Make the comments describe what the code actually does.
----
drivers/cpufreq/cpufreq_conservative.c +7 -7
@@ -44,10 +44,11 @@/* * The polling frequency of this governor depends on the capability of -* the processor. Default polling frequency is 1000 times the transition +* the processor. Default polling frequency is 100000 times the transition * latency of the processor. The governor will work on any processor with -* transition latency <= 10mS, using appropriate sampling -* rate. +* transition latency <= 10mS, using an appropriate sampling interval. +* The "sampling_rate" used is actually a sampling interval. This means that +* CPU speed is adjusted more often if this number is lower. * For CPUs with transition latency > 10mS (mostly drivers with CPUFREQ_ETERNAL) * this governor will not work. * All times here are in uS.
@@ -324,15 +325,14 @@/* * The default safe range is 20% to 80% -* Every sampling_rate, we check +* Every sampling_rate microseconds, we check * - If current idle time is less than 20%, then we try to * increase frequency -* Every sampling_rate*sampling_down_factor, we check +* Every sampling_rate*sampling_down_factor microseconds, we check * - If current idle time is more than 80%, then we try to * decrease frequency * -* Any frequency increase takes it to the maximum frequency. -* Frequency reduction happens at minimum steps of +* Any frequency change (both up and down) happens at minimum steps of * 5% (default) of max_frequency */
drivers/cpufreq/cpufreq_ondemand.c +5 -4
@@ -41,8 +41,9 @@* The polling frequency of this governor depends on the capability of * the processor. Default polling frequency is 1000 times the transition * latency of the processor. The governor will work on any processor with -* transition latency <= 10mS, using appropriate sampling -* rate. +* transition latency <= 10mS, using appropriate sampling interval. +* The "sampling_rate" used is actually a sampling interval. This means that +* CPU speed is adjusted more often if this number is lower. * For CPUs with transition latency > 10mS (mostly drivers with CPUFREQ_ETERNAL) * this governor will not work. * All times here are in uS.
@@ -256,9 +257,9 @@ policy = this_dbs_info->cur_policy;/* -* Every sampling_rate, we check, if current idle time is less +* Every sampling_rate uS, we check, if current idle time is less * than 20% (default), then we try to increase frequency -* Every sampling_rate*sampling_down_factor, we look for a the lowest +* Every sampling_rate*sampling_down_factor uS, we look for a the lowest * frequency which can sustain the load while keeping idle time over * 30%. If such a frequency exist, we try to decrease to this frequency. *
PATCH 2/2 cpufreq_conservative units weirdness
It seems to me that there is some discrepancy between cpufreq_ondemand and cpufreq_conservative. Specifically, the ondemand driver allows a minimum sampling rate of 500 times the transition latency. However, in the conservative driver increases the DEFAULT_MULTIPLIER from 1000 to 100000 without adjusting MIN_SAMPLING_RATE accordingly.
To correct this behaviour, it would be possible to simply adjust the DEFAULT_MULTIPLIER to 1000, however, this would change the behaviour of the default install. Instead I suggest adjusting the minimum sample rate so that people who want to adjust their sampling rates to lower values (which should still be safe) can chose to do so.
------
Allow users of cpufreq_conservative the same minimum sampling rate than what is allowed by cpufreq_ondemand.
------
drivers/cpufreq/cpufreq_conservative.c 2005-12-02 13:21:11.000000000 +0100 renamed from drivers/cpufreq/cpufreq_conservative.c 2005-12-02 13:19:48.000000000 +0100 +1 -1
@@ -54,7 +54,7 @@ * All times here are in uS. */ static unsigned int def_sampling_rate; -#define MIN_SAMPLING_RATE (def_sampling_rate / 2) +#define MIN_SAMPLING_RATE (def_sampling_rate / 200) #define MAX_SAMPLING_RATE (500 * def_sampling_rate) #define DEF_SAMPLING_RATE_LATENCY_MULTIPLIER (100000) #define DEF_SAMPLING_DOWN_FACTOR (5)