Chapter 3. Tuned

3.1. Tuned Overview

Tuned is a daemon that uses udev to monitor connected devices and statically and dynamically tunes system settings according to a selected profile. Tuned is distributed with a number of predefined profiles for common use cases like high throughput, low latency, or powersave. It is possible to modify the rules defined for each profile and customize how to tune a particular device. To revert all changes made to the system settings by a certain profile, you can either switch to another profile or deactivate the tuned service.


Starting with Red Hat Enterprise Linux 7.2, you can run Tuned in no-daemon mode, which does not require any resident memory. In this mode, tuned applies the settings and exits. The no-daemon mode is disabled by default because a lot of tuned functionality is missing in this mode, including D-Bus support, hot-plug support, or rollback support for settings. To enable no-daemon mode, set the following in the /etc/tuned/tuned-main.conf file: daemon = 0.
Static tuning mainly consists of the application of predefined sysctl and sysfs settings and one-shot activation of several configuration tools like ethtool. Tuned also monitors the use of system components and tunes system settings dynamically based on that monitoring information.
Dynamic tuning accounts for the way that various system components are used differently throughout the uptime for any given system. For example, the hard drive is used heavily during startup and login, but is barely used later when the user might mainly work with applications such as web browsers or email clients. Similarly, the CPU and network devices are used differently at different times. Tuned monitors the activity of these components and reacts to the changes in their use.
As a practical example, consider a typical office workstation. Most of the time, the Ethernet network interface is very inactive. Only a few emails go in and out every once in a while or some web pages might be loaded. For those kinds of loads, the network interface does not have to run at full speed all the time, as it does by default. Tuned has a monitoring and tuning plug-in for network devices that can detect this low activity and then automatically lower the speed of that interface, typically resulting in a lower power usage. If the activity on the interface increases for a longer period of time, for example because a DVD image is being downloaded or an email with a large attachment is opened, tuned detects this and sets the interface speed to maximum to offer the best performance while the activity level is so high. This principle is used for other plug-ins for CPU and hard disks as well.
Dynamic tuning is globally disabled in Red Hat Enterprise Linux and can be enabled by editing the /etc/tuned/tuned-main.conf file and changing the dynamic_tuning flag to 1.

3.1.1. Plug-ins

Tuned uses two types of plugins: monitoring plugins and tuning plugins. Monitoring plugins are used to get information from a running system. Currently, the following monitoring plugins are implemented:
Gets disk load (number of IO operations) per device and measurement interval.
Gets network load (number of transferred packets) per network card and measurement interval.
Gets CPU load per CPU and measurement interval.
The output of the monitoring plugins can be used by tuning plugins for dynamic tuning. Currently implemented dynamic tuning algorithms try to balance the performance and powersave and are therefore disabled in the performance profiles (dynamic tuning for individual plugins can be enabled or disabled in the tuned profiles). Monitoring plugins are automatically instantiated whenever their metrics are needed by any of the enabled tuning plugins. If two tuning plugins require the same data, only one instance of the monitoring plugin is created and the data is shared.
Each tuning plugin tunes an individual subsystem and takes several parameters that are populated from the tuned profiles. Each subsystem can have multiple devices (for example, multiple CPUs or network cards) that are handled by individual instances of the tuning plugins. Specific settings for individual devices are also supported. The supplied profiles use wildcards to match all devices of individual subsystems (for details on how to change this, refer to Section 3.1.3, “Custom Profiles”), which allows the plugins to tune these subsystems according to the required goal (selected profile) and the only thing that the user needs to do is to select the correct tuned profile.
Currently, the following tuning plugins are implemented (only some of these plugins implement dynamic tuning, parameters supported by plugins are also listed):
Sets the CPU governor to the value specified by the governor parameter and dynamically changes the PM QoS CPU DMA latency according to the CPU load. If the CPU load is lower than the value specified by the load_threshold parameter, the latency is set to the value specified by the latency_high parameter, otherwise it is set to value specified by latency_low. Also the latency can be forced to a specific value without being dynamically changed further. This can be accomplished by setting the force_latency parameter to the required latency value.
Dynamically sets the FSB speed according to the CPU load; this feature can be found on some netbooks and is also known as the Asus Super Hybrid Engine. If the CPU load is lower or equal to the value specified by the load_threshold_powersave parameter, the plugin sets the FSB speed to the value specified by the she_powersave parameter (for details about the FSB frequencies and corresponding values, see the kernel documentation, the provided defaults should work for most users). If the CPU load is higher or equal to the value specified by the load_threshold_normal parameter, it sets the FSB speed to the value specified by the she_normal parameter. Static tuning is not supported and the plugin is transparently disabled if the hardware support for this feature is not detected.
Configures wake-on-lan to the values specified by the wake_on_lan parameter (it uses same syntax as the ethtool utility). It also dynamically changes the interface speed according to the interface utilization.
Sets various sysctl settings specified by the plugin parameters. The syntax is name=value, where name is the same as the name provided by the sysctl tool. Use this plugin if you need to change settings that are not covered by other plugins (but prefer specific plugins if the settings are covered by them).
Sets autosuspend timeout of USB devices to the value specified by the autosuspend parameter. The value 0 means that autosuspend is disabled.
Enables or disables transparent huge pages depending on the Boolean value of the transparent_hugepages parameter.
Sets the autosuspend timeout for audio codecs to the value specified by the timeout parameter. Currently snd_hda_intel and snd_ac97_codec are supported. The value 0 means that the autosuspend is disabled. You can also enforce the controller reset by setting the Boolean parameter reset_controller to true.
Sets the elevator to the value specified by the elevator parameter. It also sets ALPM to the value specified by the alpm parameter, ASPM to the value specified by the aspm parameter, scheduler quantum to the value specified by the scheduler_quantum parameter, disk spindown timeout to the value specified by the spindown parameter, disk readahead to the value specified by the readahead parameter, and can multiply the current disk readahead value by the constant specified by the readahead_multiply parameter. In addition, this plugin dynamically changes the advanced power management and spindown timeout setting for the drive according to the current drive utilization. The dynamic tuning can be controlled by the Boolean parameter dynamic and is enabled by default.
Enables or disables barriers for mounts according to the Boolean value of the disable_barriers parameter.
This plugin can be used for the execution of an external script that is run when the profile is loaded or unloaded. The script is called by one argument which can be start or stop (it depends on whether the script is called during the profile load or unload). The script file name can be specified by the script parameter. Note that you need to correctly implement the stop action in your script and revert all setting you changed during the start action, otherwise the roll-back will not work. For your convenience, the functions Bash helper script is installed by default and allows you to import and use various functions defined in it. Note that this functionality is provided mainly for backwards compatibility and it is recommended that you use it as the last resort and prefer other plugins if they cover the required settings.
Sets various sysfs settings specified by the plugin parameters. The syntax is name=value, where name is the sysfs path to use. Use this plugin in case you need to change some settings that are not covered by other plugins (please prefer specific plugins if they cover the required settings).
Sets various powersave levels on video cards (currently only the Radeon cards are supported). The powersave level can be specified by using the radeon_powersave parameter. Supported values are: default, auto, low, mid, high, and dynpm. For details, refer to Note that this plugin is experimental and the parameter may change in the future releases.
Adds paramaters to the kernel boot command line. This plugin supports the grub-legacy and grub2 packages and also Grub with Extensible Firmware Interface (EFI). Customized non-standard location of the grub2 configuration file can be specified by the grub2_cfg_file option. The parameters are added to the current grub configuration and its templates. The machine needs to be rebooted for the kernel parameters to take effect.
The parameters can be specified by the following syntax:
	cmdline=arg1 arg2 ... argn.

3.1.2. Installation and Usage

To install the tuned package, run, as root, the following command:
yum install tuned
Installation of the tuned package also presets the profile which should be the best for you system. Currently the default profile is selected according the following customizable rules:
This is pre-selected on Red Hat Enterprise Linux 7 operating systems which act as compute nodes. The goal on such systems is the best throughput performance.
This is pre-selected on virtual machines. The goal is best performance. If you are not interested in best performance, you would probably like to change it to the balanced or powersave profile (see bellow).
This is pre-selected in all other cases. The goal is balanced performance and power consumption.
To start tuned, run, as root, the following command:
systemctl start tuned
To enable tuned to start every time the machine boots, type the following command:
systemctl enable tuned
For other tuned control such as selection of profiles and other, use:
This command requires the tuned service to be running.
To view the available installed profiles, run:
tuned-adm list
To view the currently activated profile, run:
tuned-adm active
To select or activate a profile, run:
tuned-adm profile profile
For example:
tuned-adm profile powersave
As an experimental feature it is possible to select more profiles at once. The tuned application will try to merge them during the load. If there are conflicts the settings from the last specified profile will take precedence. This is done automatically and there is no checking whether the resulting combination of parameters makes sense. If used without thinking, the feature may tune some parameters the opposite way which may be counterproductive. An example of such situation would be setting the disk for the high throughput by using the throughput-performance profile and concurrently setting the disk spindown to the low value by the spindown-disk profile. The following example optimizes the system for run in a virtual machine for the best performance and concurrently tune it for the low power consumption while the low power consumption is the priority:
tuned-adm profile virtual-guest powersave
To let tuned recommend you the best suitable profile for your system without changing any existing profiles and using the same logic as used during the installation, run the following command:
tuned-adm recommend
Tuned itself has additional options that you can use when you run it manually. However, this is not recommended and is mostly intended for debugging purposes. The available options can be viewing using the following command:
tuned --help

3.1.3. Custom Profiles

Distribution-specific profiles are stored in the /usr/lib/tuned/ directory. Each profile has its own directory. The profile consists of the main configuration file called tuned.conf, and optionally other files, for example helper scripts.
If you need to customize a profile, copy the profile directory into the /etc/tuned/ directory, which is used for custom profiles. If there are two profiles of the same name, the profile included in /etc/tuned/ is used.
You can also create your own profile in the /etc/tuned/ directory to use a profile included in /usr/lib/tuned/ with only certain parameters adjusted or overridden.
The tuned.conf file contains several sections. There is one [main] section. The other sections are configurations for plugins instances. All sections are optional including the [main] section. Lines starting with the hash sign (#) are comments.
The [main] section has the following option:
The specified profile will be included, e.g. include=powersave will include the powersave profile.
Sections describing plugins instances are formatted in the following way:
NAME is the name of the plugin instance as it is used in the logs. It can be an arbitrary string. TYPE is the type of the tuning plugin. For a list and descriptions of the tuning plugins refer to Section 3.1.1, “Plug-ins”. DEVICES is the list of devices this plugin instance will handle. The devices line can contain a list, a wildcard (*), and negation (!). You can also combine rules. If there is no devices line all devices present or later attached on the system of the TYPE will be handled by the plugin instance. This is same as using devices=*. If no instance of the plugin is specified, the plugin will not be enabled. If the plugin supports more options, they can be also specified in the plugin section. If the option is not specified, the default value will be used (if not previously specified in the included plugin). For the list of plugin options refer to Section 3.1.1, “Plug-ins”).

Example 3.1. Describing plugins instances

The following example will match everything starting with sd, such as sda or sdb and doesn't disable barriers on them:
The following example will match everything except sda1 and sda2:
devices=!sda1, !sda2 
In cases where you do not need custom names for the plugin instance and there is only one definition of the instance in your configuration file, Tuned supports the following short syntax:
In this case, it is possible to omit the type line. The instance will then be referred to with a name, same as the type. The previous example could be then rewritten into:
If the same section is specified more than once using the include option, then the settings are merged. If they cannot be merged due to a conflict, the last conflicting definition overrides the previous settings in conflict. Sometimes, you do not know what was previously defined. In such cases, you can use the replace boolean option and set it to true. This will cause all the previous definitions with the same name to be overwritten and the merge will not happen.
You can also disable the plugin by specifying the enabled=false option. This has the same effect as if the instance was never defined. Disabling the plugin can be useful if you are redefining the previous definition from the include option and do not want the plugin to be active in your custom profile.
Most of the time the device can be handled by one plugin instance. If the device matches multiple instances definitions, an error is reported.
The following is an example of a custom profile that is based on the balanced profile and extends it the way that ALPM for all devices is set to the maximal powersaving.

The following is an example of a custom profile that adds isolcpus=2 to the kernel boot command line:
The machine needs to be rebooted after the profile is applied for the changes to take effect.

3.1.4. Tuned-adm

A detailed analysis of a system can be very time-consuming. Red Hat Enterprise Linux 7 includes a number of predefined profiles for typical use cases that you can easily activate with the tuned-adm utility. You can also create, modify, and delete profiles.
To list all available profiles and identify the current active profile, run:
tuned-adm list
To only display the currently active profile, run:
tuned-adm active
To switch to one of the available profiles, run:
tuned-adm profile profile_name
for example:
tuned-adm profile latency-performance
To disable all tuning:
tuned-adm off
The following is a list of profiles which are installed with the base package:
The default power-saving profile. It is intended to be a comprimise between performance and power consumption. It tries to use auto-scaling and auto-tunning whenever possible. It has good results for most loads. The only drawback is the increased latency. In the current tuned release it enables the CPU, disk, audio and video plugins and activates the ondemand governor. The radeon_powersave is set to auto.
A profile for maximum power saving performance. It can throttle the performance in order to minimize the actual power consumption. In the current tuned release it enables USB autosuspend, WiFi power saving and ALPM power savings for SATA host adapters. It also schedules multi-core power savings for systems with a low wakeup rate and activates the ondemand governor. It enables AC97 audio power saving or, depending on your system, HDA-Intel power savings with a 10 seconds timeout. In case your system contains supported Radeon graphics card with enabled KMS it configures it to automatic power saving. On Asus Eee PCs a dynamic Super Hybrid Engine is enabled.


The powersave profile may not always be the most efficient. Consider there is a defined amount of work that needs to be done, for example a video file that needs to be transcoded. Your machine can consume less energy if the transcoding is done on the full power, because the task will be finished quickly, the machine will start to idle and can automatically step-down to very efficient power save modes. On the other hand if you transcode the file with a throttled machine, the machine will consume less power during the transcoding, but the process will take longer and the overall consumed energy can be higher. That is why the balanced profile can be generally a better option.
A server profile optimized for high throughput. It disables power savings mechanisms and enables sysctl settings that improve the throughput performance of the disk, network IO and switched to the deadline scheduler. CPU governor is set to performance.
A server profile optimized for low latency. It disables power savings mechanisms and enables sysctl settings that improve the latency. CPU governor is set to performance and the CPU is locked to the low C states (by PM QoS).
A profile for low latency network tuning. It is based on the latency-performance profile. It additionally disables transparent hugepages, NUMA balancing and tunes several other network related sysctl parameters.
Profile for throughput network tuning. It is based on the throughput-performance profile. It additionally increases kernel network buffers.
A profile designed for virtual guests based on the enterprise-storage profile that, among other tasks, decreases virtual memory swappiness and increases disk readahead values. It does not disable disk barriers.
A profile designed for virtual hosts based on the enterprise-storage profile that, among other tasks, decreases virtual memory swappiness, increases disk readahead values and enables more aggresive \ of dirty pages.
A profile optimized for Oracle databases loads based on throughput-performance profile. It additionaly disables transparent huge pages and modifies some other performance related kernel parameters. This profile is provided by tuned-profiles-oracle package. It is available in Red Hat Enterprise Linux 6.8 and later.
A profile optimized for desktops, based on the balanced profile. It additionally enables scheduler autogroups for better response of interactive applications.


There may be more product specific or 3rd party Tuned profiles available. Such profiles are usually provided by separate RPM packages.
Additional predefined profiles can be installed with the tuned-profiles-compat package available in the Optional channel. These profiles are intended for backward compatibility and are no longer developed. The generalized profiles from the base package will mostly perform the same or better. If you do not have specific reason for using them, please prefer the above mentioned profiles from the base package. The compat profiles are following:
This has the lowest impact on power saving of the available profiles and only enables CPU and disk plugins of tuned.
A power-saving profile directed at desktop systems. Enables ALPM power saving for SATA host adapters as well as the CPU, Ethernet, and disk plugins of tuned.
A medium-impact power-saving profile directed at laptops running on AC. Enables ALPM powersaving for SATA host adapters, Wi-Fi power saving, as well as the CPU, Ethernet, and disk plugins of tuned.
A high-impact power-saving profile directed at laptops running on battery. In the current tuned implementation it is an alias for the powersave profile.
A power-saving profile for machines with classic HDDs to maximize spindown time. It disables the tuned power savings mechanism, disables USB autosuspend, disables Bluetooth, enables Wi-Fi power saving, disables logs syncing, increases disk write-back time, and lowers disk swappiness. All partitions are remounted with the noatime option.
A server profile directed at enterprise-class storage, maximizing I/O throughput. It activates the same settings as the throughput-performance profile, multiplies readahead settings, and disables barriers on non-root and non-boot partitions.


Use the atomic-host profile on physical machines, and the atomic-guest profile on virtual machines.
To enable the tuned profiles for Red Hat Enterprise Linux Atomic Host, install the tuned-profiles-atomic package. Run, as root, the following command:
yum install tuned-profiles-atomic
The two tuned profiles for Red Hat Enterprise Linux Atomic Host are:
A profile optimized for Red Hat Enterprise Linux Atomic Host, when used as a host system on a bare-metal server, using the throughput-performance profile. It additionally increases SELinux AVC cache, PID limit, and tunes netfilter connections tracking.
A profile optimized for Red Hat Enterprise Linux Atomic Host, when used as a guest system based on the virtual-guest profile. It additionally increases SELinux AVC cache, PID limit, and tunes netfilter connections tracking.


There may be more product-specific or 3rd-party tuned profiles available. These profiles are usually provided by separate RPM packages. Three tuned profiles are available that enable to edit the kernel command line: realtime, realtime-virtual-host and realtime-virtual-guest.
To enable the realtime profile, install the tuned-profiles-realtime package. Run, as root, the following command:
yum install tuned-profiles-realtime
To enable the realtime-virtual-host and realtime-virtual-guest profiles, install the tuned-profiles-nfv package. Run, as root, the following command:
yum install tuned-profiles-nfv

3.1.5. Powertop2tuned

The powertop2tuned utility is a tool that allows you to create custom tuned profiles from the PowerTOP suggestions.
To install the powertop2tuned application, run the following command as root:
yum install tuned-utils
To create a custom profile, run the following command as root:
powertop2tuned new_profile_name
By default it creates the profile in the /etc/tuned directory and it bases it on the currently selected tuned profile. For safety reasons all PowerTOP tunings are initially disabled in the new profile. To enable them uncomment the tunings of your interest in the /etc/tuned/profile/tuned.conf. You can use the --enable or -e option that will generate the new profile with most of the tunings suggested by PowerTOP enabled. Some dangerous tunings like the USB autosuspend will still be disabled. If you really need them you will have to uncomment them manually. By default, the new profile is not activated. To activate it run the following command:
tuned-adm profile new_profile_name
For a complete list of the options powertop2tuned supports, type in the following command:
powertop2tuned --help