Performance regression in 2.6.30-rc1

[poornima nayak <mpnayak@linux.vnet.ibm.com>]

[-- Attachment #1: Type: text/plain, Size: 1935 bytes --]

Hi 

By executing kernbench on 2.6.30-rc1 we observed there is a performance
regression in 2.6.30-rc1. Then git-bisect was done between v2.6.29 and
v2.6.30-rc5, after 13 iterations identified the attached patch is
causing regression.

Performance data of 2.6.29 without applying the attached patch.
param-version
testname
elapsed-avg
elapsed-std
2.6.29'
pm_kernbench.Version-none-threads=2-sched_mc=2
             221.1
              0.81
2.6.29'
pm_kernbench.Version-none-threads=4-sched_mc=0
            115.09
               0.6
2.6.29'
pm_kernbench.Version-none-threads=4-sched_mc=2
            109.05
              0.25
2.6.29'
pm_kernbench.Version-none-threads=8-sched_mc=2
              60.4
              0.38
2.6.29'
pm_kernbench.Version-none-threads=8-sched_mc=0
             65.23
              0.34
2.6.29'
pm_kernbench.Version-none-threads=2-sched_mc=0
            231.61
              0.59

Performance data of 2.6.29 after applying the attached patch.
param-version
testname
elapsed-avg
elapsed-std
2.6.29'
pm_kernbench.Version-thir-bisect-threads=2-sched_mc=0
            203.77
              0.48
2.6.29'
pm_kernbench.Version-thir-bisect-threads=8-sched_mc=0
             64.38
              0.25
2.6.29'
pm_kernbench.Version-thir-bisect-threads=4-sched_mc=0
            102.46
               0.1
2.6.29'
pm_kernbench.Version-thir-bisect-threads=8-sched_mc=2
             59.94
              0.46
2.6.29'
pm_kernbench.Version-thir-bisect-threads=4-sched_mc=2
            106.84
              0.28
2.6.29'
pm_kernbench.Version-thir-bisect-threads=2-sched_mc=2
            199.44
              0.44

Performance issue here is when sched_mc_power_savings is set 2 and
kernbench is triggered with 4 threads the value of 'elapsed time' is
more then sched_mc_power_savings is set to 0. Expectation is elapsed
time should be less when sched_mc_power_savings set 2 compared to
sched_mc_power_savings set to 0.

Regds
Poornima

[-- Attachment #2: performance_reg.patch --]
[-- Type: text/x-patch, Size: 900 bytes --]

diff --git a/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c b/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
index 4b1c319..89c676d 100644
--- a/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
+++ b/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
@@ -680,6 +680,18 @@ static int acpi_cpufreq_cpu_init(struct cpufreq_policy *policy)
 			    perf->states[i].transition_latency * 1000;
 	}
 
+	/* Check for high latency (>20uS) from buggy BIOSes, like on T42 */
+	if (perf->control_register.space_id == ACPI_ADR_SPACE_FIXED_HARDWARE &&
+	    policy->cpuinfo.transition_latency > 20 * 1000) {
+		static int print_once;
+		policy->cpuinfo.transition_latency = 20 * 1000;
+		if (!print_once) {
+			print_once = 1;
+			printk(KERN_INFO "Capping off P-state tranision latency"
+				" at 20 uS\n");
+		}
+	}
+
 	data->max_freq = perf->states[0].core_frequency * 1000;
 	/* table init */
 	for (i=0; i<perf->state_count; i++) {