From: Thomas Renninger <trenn@suse.de>
Subject: CPUFREQ: ondemand: Limit default sampling rate to 300ms max.
References: bnc#464461
Patch-Mainline: never, SLE11 only

Modified for SP1 by Jiri Bohac <jbohac@suse.cz>

HW cpufreq drivers (e.g. all non-acpi AMD) may report too high latency values.
The default sampling rate (how often the ondemand/conservative governor
checks for frequency adjustments) may therefore be much too high,
resulting in performance loss.

Restrict default sampling rate to 300ms. 333ms sampling rate is field
tested with userspace governors, 300ms should be a fine maximum default
value for the ondemand kernel governor for all HW out there.

Set default up_threshold to 40 on multi core systems.
This should avoid effects where two CPU intensive threads are waiting on
each other on separate cores. On a single core machine these would all be
processed on one core resulting in higher utilization of the one core.

---
 drivers/cpufreq/cpufreq_ondemand.c |   24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -35,6 +35,7 @@
 #define MICRO_FREQUENCY_MIN_SAMPLE_RATE		(10000)
 #define MIN_FREQUENCY_UP_THRESHOLD		(11)
 #define MAX_FREQUENCY_UP_THRESHOLD		(100)
+#define MAX_DEFAULT_SAMPLING_RATE		(300 * 1000U)
 
 /*
  * The polling frequency of this governor depends on the capability of
@@ -736,6 +737,29 @@ static int cpufreq_governor_dbs(struct c
 			dbs_tuners_ins.sampling_rate =
 				max(min_sampling_rate,
 				    latency * LATENCY_MULTIPLIER);
+			/*
+			 * Cut def_sampling rate to 300ms if it was above,
+			 * still consider to not set it above latency
+			 * transition * 100
+			 */
+			if (dbs_tuners_ins.sampling_rate > MAX_DEFAULT_SAMPLING_RATE) {
+				dbs_tuners_ins.sampling_rate =
+					max(min_sampling_rate, MAX_DEFAULT_SAMPLING_RATE);
+				printk(KERN_INFO "CPUFREQ: ondemand sampling "
+				       "rate set to %d ms\n",
+				       dbs_tuners_ins.sampling_rate / 1000);
+			}
+			/*
+			 * Be conservative in respect to performance.
+			 * If an application calculates using two threads
+			 * depending on each other, they will be run on several
+			 * CPU cores resulting on 50% load on both.
+			 * SLED might still want to prefer 80% up_threshold
+			 * by default, but we cannot differ that here.
+			 */
+			if (num_online_cpus() > 1)
+				dbs_tuners_ins.up_threshold =
+					DEF_FREQUENCY_UP_THRESHOLD / 2;
 			dbs_tuners_ins.io_is_busy = should_io_be_busy();
 		}
 		mutex_unlock(&dbs_mutex);