[PATCH 2.6.14 1/2] cpufreq_conservative units weirdness

[PATCH 2.6.14 1/2] cpufreq_conservative units weirdness

[Felix Braun]

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.

Signed-off-by: Felix Braun <Felix.Braun@mail.McGill.ca>
----

diff -ruN a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c
--- a/drivers/cpufreq/cpufreq_conservative.c	2005-10-28 10:42:33.000000000 +0200
+++ b/drivers/cpufreq/cpufreq_conservative.c	2005-12-02 13:19:48.000000000 +0100
@@ -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 
 	 */
 
diff -ruN a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c
--- a/drivers/cpufreq/cpufreq_ondemand.c	2005-12-02 13:28:39.000000000 +0100
+++ b/drivers/cpufreq/cpufreq_ondemand.c	2005-12-02 13:25:31.000000000 +0100
@@ -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.6.14 2/2] cpufreq_conservative units weirdness

[Felix Braun]

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.

Signed-off-by: Felix Braun <Felix.Braun@mail.McGill.ca>

------

diff -ruN a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c
--- a/drivers/cpufreq/cpufreq_conservative.c    2005-12-02 13:19:48.000000000 +0100
+++ b/drivers/cpufreq/cpufreq_conservative.c    2005-12-02 13:21:11.000000000 +0100
@@ -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)