tuned-2.4.0 released
by Jaroslav Skarvada
This is to announce tuned-2.4.0, a stable release.
Tuned is a tool that performs monitoring and adaptive configuration
of the system according to selected profile.
The 2.4.0 contains many bug fixes and also introduces new features.
Noteworthy changes since previous release:
- fixed traceback if profile cannot be loaded (rhbz#953128)
- powertop2tuned: fixed traceback if rewriting file instead of directory (rhbz#963441)
- daemon: fixed race condition in start/stop
- improved timings, it can be fine tuned in /etc/tuned/tuned-main.conf (rhbz#1028122)
- throughput-performance: altered dirty ratios for better performance (rhbz#1043533)
- latency-performance: leaving THP on its default (rhbz#1064510)
- used throughput-performance profile on server by default (rhbz#1063481)
- network-latency: added new profile (rhbz#1052418)
- network-throughput: added new profile (rhbz#1052421)
- recommend.conf: fixed config file (rhbz#1069123)
- spec: added kernel-tools requirement (rhbz#1073008)
- systemd: added cpupower.service conflict (rhbz#1073392)
- balanced: used medium_power ALPM policy
- added support for >, < assignment modifiers in tuned.conf
- handled root block devices
- balanced: used conservative CPU governor (rhbz#1124125)
- plugins: added selinux plugin
- plugin_net: added nf_conntrack_hashsize parameter
- profiles: added atomic-host profile (rhbz#1091977)
- profiles: added atomic-guest profile (rhbz#1091979)
- moved profile autodetection from post install script to tuned daemon (rhbz#1144067)
- profiles: included sap-hana and sap-hana-vmware profiles
- man: structured profiles manual pages according to sub-packages
- added missing hdparm dependency (rhbz#1144858)
- improved error handling of switch_profile (rhbz#1068699)
- tuned-adm: active: detect whether tuned deamon is running (rhbz#1068699)
- spec: removed active_profile from RPM verification (rhbz#1104126)
- plugin_disk: readahead value can be now specified in sectors (rhbz#1127127)
- plugins: added bootloader plugin (rhbz#1044111)
- plugin_disk: added error counter to hdparm calls
- plugins: added scheduler plugin (rhbz#1100826)
- added tuned-gui with profile editor
Download:
http://fedorahosted.org/releases/t/u/tuned/tuned-2.4.0.tar.bz2
Upstream homepage:
http://fedorahosted.org/tuned/
6 years, 6 months
[tuned] #49: Provide a way to disable dynamic updates per plugin
by fedora-badges
#49: Provide a way to disable dynamic updates per plugin
--------------------------+---------------------
Reporter: ework | Owner:
Type: enhancement | Status: new
Priority: major | Component: plugins
Version: 2.0 | Keywords: net
Blocked By: | Blocking:
--------------------------+---------------------
I use synergy to share a mouse & keyboard between my desktop and laptop.
Whenever I start to download something (for example a Fedora ISO), I lose
my connection for about 30 sec due to the ethernet interface speed change.
Even worse the download fails because the connection is lost for this
brief period of time. I'd suggest that at least this change doesn't occur
when on AC as a default policy, but for me personally a way to disable
dynamic updates per plugin without having to hack the python code would be
nice. I couldn't seem to find anywhere in the documentation that mentions
how to do this.
--
Ticket URL: <https://fedorahosted.org/tuned/ticket/49>
tuned <https://fedorahosted.org/tuned/>
A daemon that performs monitoring and adaptive configuration of devices in the system.
7 years, 9 months
tuned plugin to manage application tuning hints?
by Clark Williams
Jaroslav,
This is an attempt to firm up the rather vague discussion I had with
you on IRC. Hope it makes sense.
Currently, tuned manages system-wide tuning parameters for realtime
and NFV systems, mainly cpu isolation. That's fine for simple
deployments where we boot up, isolate some cpus, then start an
application that runs on those isolated cpus. It's not so good when we
start dealing with subsystems like Open VirtualSwitch (ovs) or stacks
like OpenStack. Those components have their own startup logic and
could use application specific tuning directions, such as cpu
placement, scheduling policy/priority, IRQ placement, etc.
Essentially, I'm asking that we come up with a way for tuned to parse
a file (or files) that contain tuning keypairs, and then provide those
keypairs when asked. The tuning info would be in one place and tuned
could have some logic to verify that the tuning's don't conflict.
For example, let's say a system has 44 cores and using
tuned-profiles-nfv, we've specified that 8 of those cores should be
isolated (isolcpus=36-43). Additionally, we want to run ovs on four of
the cores and my-special-app on the other four, so we could have a
file somewhere that looks like this:
[ovs]
cpulist=36-39
policy=fifo
priority=20
[my-special-app]
cpulist=40-43
policy=fifo
priority=10
What I envision is the ovs startup logic querying tuned with the key
'ovs' and getting back the keypairs above, which it could then use
properly to place the ovs threads on the appropriate cpus at the
specified scheduling policy and priority. Ditto when the
my-special-app startup logic runs.
Additionally, we don't currently have a good way to add arbitrary
kernel parameters to the kernel command line. We can get isolcpus=
added via the tuned-profiles-{realtime,nfv} packages, but if you want
to add intel_idle.max_cstate= or rcu_nocb_poll, or a host of others,
you're off editing /etc/default/grub. It might be nice to have a file
section called 'boot', where you can add kernel command line
parameters and possibly IRQ affinity placement. Not a high priority
for me, but it might be nice to collect all this tuning info into one
place:
[boot]
isolcpus=36-43
irq_affinity= !${isolcpus}
params='debug intel_idle.max_cstate=1'
[ovs]
cpulist=36-39
policy=fifo
priority=20
[my-special-app]
cpulist=40-43
policy=fifo
priority=10
Bottom line is that I think I'm talking about a tuned plugin that
becomes a clearinghouse for tuning hints. The plugin parses the info,
checks to make sure that things like cpu lists and irqs all make
sense, possibly updates the grub config with info from the [boot]
section and then just replies when someone queries for info using a
particular key (e.g. 'ovs') with a list of the keypairs.
Thoughts?
Clark
7 years, 9 months
Re: [PATCH 1/2] tuned: Adding a command "sampling_down_factor" to cpu
plugin
by Akshay Adiga
On 06/18/2016 12:06 AM, Akshay Adiga wrote:
> 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..de5b2ce 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": 1,
> "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):
Does this patch look good ? Any suggestion ?
Regards
Akshay Adiga
7 years, 10 months
[PATCH 1/2] tuned: Adding a command "sampling_down_factor" to cpu plugin
by Akshay Adiga
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
7 years, 10 months
Unable to set "governor" before setting "sampling_down_factor"
by Akshay Adiga
Hi Jaroslav,
I wrote the following patch and a profile to set sampling_down_factor.
- The knob for sampling_down_factor only appears after the governor is changed to either
ondemand or conservative.
It appears in/sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor for ondemand
It appears in
/sys/devices/system/cpu/cpufreq/conservative/sampling_down_factor for
conservative. It is necessary that the governor requested in the profile
be set before setting/getting sampling_down_factor.
With this patch it fails to set the sampling_down_factor, as the tuned has not switched to new governor.
I did some experiments by adding the following debug logs :
@command_set("sampling_down_factor")
def _set_sampling_down_factor(self,sampling_down_factor,sim):
cpufreq_sys_dir = "/sys/devices/system/cpu/cpufreq/"
data = self._cmd.read_file("/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor").strip()
log.info("gov is %s" %data)
log.info("%s : %s"% ("ondemand",str(os.path.exists(cpufreq_sys_dir + "ondemand"))))
log.info("%s : %s"% ("conservative",str(os.path.exists(cpufreq_sys_dir + "conservative"))))
...
I ran a test which did the following :
systemctl stop tuned
sleep 5
systemctl start tuned
sleep 2
tuned-adm profile balanced
sleep 2
echo "sampling_down_factor:" `cat /sys/devices/system/cpu/cpufreq/*/sampling_down_factor`
tuned-adm profile balanced-hpc
Here are the logs which i see after that :
2016-06-12 03:43:58,672 INFO tuned.plugins.plugin_cpu: setting new cpu latency 1000
2016-06-12 03:43:58,673 INFO tuned.daemon.daemon: static tuning from profile 'balanced' applied
2016-06-12 03:44:00,641 INFO tuned.daemon.daemon: stopping tunning
2016-06-12 03:44:00,724 INFO tuned.profiles.loader: loading profile: balanced-hpc
2016-06-12 03:44:00,724 INFO tuned.daemon.daemon: starting tuning
...
2016-06-12 03:44:00,759 INFO tuned.plugins.plugin_cpu: sampling_down_factor is None
2016-06-12 03:44:00,759 INFO tuned.plugins.plugin_cpu: gov is performance
2016-06-12 03:44:00,759 INFO tuned.plugins.plugin_cpu: ondemand : False
2016-06-12 03:44:00,760 INFO tuned.plugins.plugin_cpu: conservative : False
2016-06-12 03:44:00,760 INFO tuned.plugins.plugin_cpu: sampling_down_factor is set to 100
2016-06-12 03:44:00,841 INFO tuned.plugins.plugin_cpu: setting new cpu latency 1000
2016-06-12 03:44:00,841 INFO tuned.daemon.daemon: static tuning from profile 'balanced-hpc' applied
Hope i am not doing something silly here.
But, Does I was switching to default profile before setting it to requested one ?
Is there a way to ensure governor setting precedes this command ?
Is there a way tuned could set different governors to different cpus?
Known problems:
If both conservative and ondemand are being used on different cpus , sometimes i couldn't set sampling_down_rate.
I will figure out why it is happening.
balanced-hpc/tuned.conf
-------------
#
# 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
-----
diff --git a/tuned/plugins/plugin_cpu.py b/tuned/plugins/plugin_cpu.py
index 80d878a..412fcfe 100644
--- a/tuned/plugins/plugin_cpu.py
+++ b/tuned/plugins/plugin_cpu.py
@@ -48,6 +48,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,
@@ -239,6 +240,32 @@ 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/"
+ governors = ["ondemand", "conservative"]
+ #If both ondemand and conservative governors are in use we set
for both.
+ for gov in governors :
+ if os.path.exists(cpufreq_sys_dir + gov) :
+ sys_dir_path = cpufreq_sys_dir + gov
+ self._cmd.write_to_file(sys_dir_path +
"/sampling_down_factor", str(sampling_down_factor))
+ log.info("sampling_down_factor is set to %s" %
sampling_down_factor)
+ 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/"
+ governors = ["ondemand", "conservative"]
+ #If both ondemand and conservative governors are in use, both
should
+ #have same sampling_down_factor.
+ for gov in governors :
+ if os.path.exists(cpufreq_sys_dir + gov) :
+ sys_dir_path = cpufreq_sys_dir + gov
+ factor = self._cmd.read_file(sys_dir_path +
"/sampling_down_factor").strip()
+ log.info("sampling_down_factor 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):
--
Regards
Akshay Adiga
7 years, 10 months
[RFC] tuned : Adding new profile for hpc workload derived from
balanced profile
by Akshay Adiga
Hi Jaroslav,
For HPC workloads its seen that ondemand cpufreq governor introduces
some jitter.
It has been reported in several distros (eg Ubuntu, Redhat) [1]. Jitter
is mainly
due to kernel worker threads which needs to get scheduled to perform load
calculation and set frequencies.
A new cpufreq governor "schedutil" is being developed by Rafael J.
Wysocki which
seems to largely solve the problem. It hooks on to the scheduler for
load calculations
and sets frequency in interrupt contexts (hence no worker thread which
causes the problem).
But there is a long way to go before it stabilizes and reaches distros.
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.
Proposed fix through tuned :
- Adding a new balanced profile for hpc workloads called balanced-hpc.
- We could set sampling_down_parameter to 100 for this profile.
[1] https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1483586
[2] https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt
Following is a proposed patch that adds a balanced-hpc profile:
This profile derived from the balanced profile. The only changes
from balanced profile are the cpufreq governor and additional
setting of sampling_down_factor.
sampling_down_factor is set to 100.
diff --git a/profiles/balanced-hpc/scripts.sh
b/profiles/balanced-hpc/scripts.sh
new file mode 100755
index 0000000..b494e2d
--- /dev/null
+++ b/profiles/balanced-hpc/scripts.sh
@@ -0,0 +1,15 @@
+#!/bin/sh
+
+. /usr/lib/tuned/functions
+
+start() {
+ echo 100 >
/sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
+ return 0
+}
+
+stop() {
+ echo 1 >
/sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
+ return 0
+}
+
+process $@
diff --git a/profiles/balanced-hpc/tuned.conf
b/profiles/balanced-hpc/tuned.conf
new file mode 100644
index 0000000..777ef41
--- /dev/null
+++ b/profiles/balanced-hpc/tuned.conf
@@ -0,0 +1,21 @@
+#
+# tuned configuration
+#
+
+[cpu]
+governor=ondemand
+energy_perf_bias=normal
+
+[audio]
+timeout=10
+
+[video]
+radeon_powersave=auto
+
+[disk]
+# Comma separated list of devices, all devices if commented out.
+# devices=sda
+alpm=medium_power
+
+[script]
+script=scripts.sh
Regards
Akshay Adiga
7 years, 10 months
[tuned] #52: karan
by fedora-badges
#52: karan
-----------------------------+--------------------
Reporter: niviparasar245 | Owner:
Type: defect | Status: new
Priority: major | Component: daemon
Version: 2.0 | Keywords:
Blocked By: | Blocking:
-----------------------------+--------------------
kundara ki wife kown hai
--
Ticket URL: <https://fedorahosted.org/tuned/ticket/52>
tuned <https://fedorahosted.org/tuned/>
A daemon that performs monitoring and adaptive configuration of devices in the system.
7 years, 10 months
[RFC] tuned : Adding new profile for hpc workload derived from
balanced profile
by Akshay Adiga
Hi,
For HPC workloads its seen that ondemand cpufreq governor introduces some jitter.
It has been reported in several distros (eg Ubuntu, Redhat) [1]. Jitter is mainly
due to kernel worker threads which needs to get scheduled to perform load
calculation and set frequencies.
A new cpufreq governor "schedutil" is being developed by Rafael J. Wysocki which
seems to largely solve the problem. It hooks on to the scheduler for load calculations
and sets frequency in interrupt contexts (hence no worker thread which causes the problem).
But there is a long way to go before it stabilizes and reaches distros.
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.
Proposed fix through tuned :
- Adding a new balanced profile for hpc workloads called balanced-hpc.
- We could set sampling_down_parameter to 100 for this profile.
[1] https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1483586
[2] https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt
Following is a proposed patch that adds a balanced-hpc profile:
This profile derived from the balanced profile. The only changes
from balanced profile are the cpufreq governor and additional
setting of sampling_down_factor.
sampling_down_factor is set to 100.
iff --git a/profiles/balanced-hpc/scripts.sh b/profiles/balanced-hpc/scripts.sh
new file mode 100755
index 0000000..b494e2d
--- /dev/null
+++ b/profiles/balanced-hpc/scripts.sh
@@ -0,0 +1,15 @@
+#!/bin/sh
+
+. /usr/lib/tuned/functions
+
+start() {
+ echo 100 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
+ return 0
+}
+
+stop() {
+ echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
+ return 0
+}
+
+process $@
diff --git a/profiles/balanced-hpc/tuned.conf b/profiles/balanced-hpc/tuned.conf
new file mode 100644
index 0000000..777ef41
--- /dev/null
+++ b/profiles/balanced-hpc/tuned.conf
@@ -0,0 +1,21 @@
+#
+# tuned configuration
+#
+
+[cpu]
+governor=ondemand
+energy_perf_bias=normal
+
+[audio]
+timeout=10
+
+[video]
+radeon_powersave=auto
+
+[disk]
+# Comma separated list of devices, all devices if commented out.
+# devices=sda
+alpm=medium_power
+
+[script]
+script=scripts.sh
Regards
Akshay Adiga
7 years, 10 months