This patch adds a command to set sampling_down_factor a tunable parameter
available for ondemand cpufreq governors.
The tunable parameter is exposed as sys interface:
/sys/devices/system/cpu/ondemand/sampling_down_factor
Cases when this parameter is available :
1) at least one cpu should have current cpufreq governor as ondemand
2) linux kernel version > v2.6.37
Ideally the governor needs to be set before setting this parameter.
If the previous profile also had ondemand we set it right away.
Otherwise we _set_sdf = True to indicate that sampling down factor
needs to be set after setting the govenor. And _sdf_value store the
sampling down factor that needs to be set.
Usage in tuned.conf:
sampling_down_factor=<num>
<num> = factor by which the sampling has to be reduced on reaching
pmax.
Recommended setting for jitter reduction:
sampling_down_factor=100
Conservative governor too has this tunable parameter but the impact
has not yet verified. Hence adding sampling_down_factor only for
ondemand.
Signed-off-by: Akshay Adiga <akshay.adiga(a)linux.vnet.ibm.com>
---
tuned/plugins/plugin_cpu.py | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/tuned/plugins/plugin_cpu.py b/tuned/plugins/plugin_cpu.py
index 80d878a..43ea1da 100644
--- a/tuned/plugins/plugin_cpu.py
+++ b/tuned/plugins/plugin_cpu.py
@@ -30,6 +30,8 @@ class CPULatencyPlugin(base.Plugin):
self._max_perf_pct_save = None
self._no_turbo_save = None
self._cmd = commands()
+ self._set_sdf = False
+ self._sdf_value = None
def _init_devices(self):
self._devices = set()
@@ -48,6 +50,7 @@ class CPULatencyPlugin(base.Plugin):
"latency_high" : 1000,
"force_latency" : None,
"governor" : None,
+ "sampling_down_factor": None,
"energy_perf_bias" : None,
"min_perf_pct" : None,
"max_perf_pct" : None,
@@ -210,6 +213,14 @@ class CPULatencyPlugin(base.Plugin):
self._cmd.execute(["cpupower", "-c", cpu_id,
"frequency-set", "-g", str(governor)])
else:
self._cmd.write_to_file("/sys/devices/system/cpu/%s/cpufreq/scaling_governor"
% device, str(governor))
+ # _set_sdf is set only if tuned was not able to find the tunable when it was first
called
+ if self._set_sdf :
+ cpufreq_sys_dir = "/sys/devices/system/cpu/cpufreq/"
+ log.info("%s exists : %s" %(governor,str(os.path.exists(cpufreq_sys_dir +
governor))))
+ if os.path.exists(cpufreq_sys_dir + governor) and ( governor == "ondemand")
:
+ self._cmd.write_to_file(cpufreq_sys_dir + governor +
"/sampling_down_factor", str(self._sdf_value))
+ log.info("sampling_down_factor is set to %s" % self._sdf_value)
+ self._set_sdf = False
return str(governor)
@command_get("governor")
@@ -239,6 +250,30 @@ class CPULatencyPlugin(base.Plugin):
return governor
+ @command_set("sampling_down_factor")
+ def _set_sampling_down_factor(self,sampling_down_factor,sim):
+ cpufreq_sys_dir = "/sys/devices/system/cpu/cpufreq/"
+ governor = "ondemand"
+ if os.path.exists(cpufreq_sys_dir + governor) :
+ self._cmd.write_to_file(cpufreq_sys_dir + governor +
"/sampling_down_factor", str(sampling_down_factor))
+ log.info("Setting sampling down factor")
+ else :
+ #tuned is did not find the tunable, lets wait for the governor to switch
+ self._set_sdf = True
+ self._sdf_value = sampling_down_factor
+ log.info("Setting set_sdf and sdf_value")
+ return sampling_down_factor
+
+ @command_get("sampling_down_factor")
+ def _get_sampling_down_factor(self):
+ sampling_down_factor = None
+ cpufreq_sys_dir = "/sys/devices/system/cpu/cpufreq/"
+ governor = "ondemand"
+ if os.path.exists(cpufreq_sys_dir + governor) :
+ sampling_down_factor = self._cmd.read_file(sys_dir_path + governor +
"/sampling_down_factor").strip()
+ log.info("sampling_down_factor (ondemand) is %s" % sampling_down_factor)
+ return str(sampling_down_factor)
+
@command_set("energy_perf_bias", per_device=True)
def _set_energy_perf_bias(self, energy_perf_bias, device, sim):
if not self._is_cpu_online(device):
--
2.5.5
Show replies by date
For HPC workloads its seen that ondemand cpufreq governor introduces
some jitter. It has been reported in several distros (eg Ubuntu,
Redhat).
Jitter is mainly due to kernel worker threads which needs to get
scheduled to perform load calculation and set frequencies.
A fix that could reduce jitter went into ubuntu recently (only for
ppc64) [1], was by setting a ondemand governor's tuning parameter
"sampling_down_factor".
Sampling_down_factor is a multiplying factor for sampling rate (rate at
which cpu load calculation happens) when the CPU is at its highest frequency it
reduces the rate at which load calcuations are done.
By setting sampling_down_factor = 100, If cpu reaches max frequency,
the sampling rate is reduced by 100 times which reduces jitter.
Typically, sampling_rate = 10 ms,
sampling_down_factor=100 ,
resulting sampling rate = 1000ms = 1 sec
The idea is that the effect of jitter is more pronounced when the cpu
load is closer to 100%, as ondemand governor sets to max frequency
only when there is high cpu load. We could reduce the sampling rate,
when it effects the most.
This patch adds a new tuned profile "balanced-hpc" which is
derived out of balanced profile. This profile reduces jitter
that is seen with ondemand governor, by setting sampling_down_factor=100.
It uses the command sampling_down_factor introduced in the
previous patch.
Signed-off-by: Akshay Adiga <akshay.adiga(a)linux.vnet.ibm.com>
---
profiles/balanced-hpc/tuned.conf | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
create mode 100644 profiles/balanced-hpc/tuned.conf
diff --git a/profiles/balanced-hpc/tuned.conf b/profiles/balanced-hpc/tuned.conf
new file mode 100644
index 0000000..f6d4a43
--- /dev/null
+++ b/profiles/balanced-hpc/tuned.conf
@@ -0,0 +1,19 @@
+#
+# tuned configuration
+#
+
+[cpu]
+governor=ondemand
+energy_perf_bias=normal
+sampling_down_factor=100
+
+[audio]
+timeout=10
+
+[video]
+radeon_powersave=auto
+
+[disk]
+# Comma separated list of devices, all devices if commented out.
+# devices=sda
+alpm=medium_power
--
2.5.5