From: Mel Gorman <mgorman@suse.de>
Date: Mon, 25 Sep 2017 13:34:28 +0100
Subject: [PATCH] cpufreq, ondemand: Set default up_threshold to 30 on multi-core systems

References: bsc#464461,bsc#981838,bsc#1064414,bsc#1144943,bsc#1193200,bsc#1193088
Patch-Mainline: Never, SLE only

Set default up_threshold to 30 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.

SLE12-SP2: This was observed to be particularly important for HP Proliant
        platforms using pcc-cpufreq. While it is recommended that OS
        Management be configured on such platforms, it may not be. Without
        this change, the sampling rate hammers overall performance with 9%
        of time spend calling ACPI functions even when idle. Furthermore,
        workqueue activity is insanely high where many of the workers then
        collide serialising on a waitqueue.

SLE15-SP2: This was observed to be important for AMD EPYC showing large
	differences in netperf and tbench in particular. For workloads like
	hackbench, it only makes a small difference for low thread counts.
	For pgbench, it makes a big difference at low thread counts. Note
	that when this was tested that AMD EPYC load balancing was still
	broken. pcc-cpufreq results were still pending and should be updated
	when complete.
	http://laplace.suse.de/pt-master/SLE-15-SP2/0003-mgorman-acpi_cpufreq-30-threshold/dashboard.html

SLE15-SP4: This time it was evaluated on AMD Zen 1-3 and the results were
	somewhat inconsistent. It helped specjbb on Zen3 but neutral
	on Zen1-2. On Zen3, there were mild performance hits on kernel
	building and shellscript intensive workloads and otherwise mostly
	neutral. However, it has a big impact on some microbenchmarks
	such as pipe test and rapid context switching. For rapidly idling
	workloads, the fast boosting of frequency is necessary. Ultimately
	this patch may go away if the native AMD cpufreq driver reaches
	the point where it beats acpi_cpufreq.

Signed-off-by: Mel Gorman <mgorman@suse.de>
---
 drivers/cpufreq/cpufreq_ondemand.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c
index 3937acf7e026..c705b3a7771e 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -24,7 +24,7 @@
 #define DEF_FREQUENCY_UP_THRESHOLD		(80)
 #define DEF_SAMPLING_DOWN_FACTOR		(1)
 #define MAX_SAMPLING_DOWN_FACTOR		(100000)
-#define MICRO_FREQUENCY_UP_THRESHOLD		(95)
+#define MICRO_FREQUENCY_UP_THRESHOLD		(30)
 #define MICRO_FREQUENCY_MIN_SAMPLE_RATE		(10000)
 #define MIN_FREQUENCY_UP_THRESHOLD		(1)
 #define MAX_FREQUENCY_UP_THRESHOLD		(100)