Language and Page Formatting Options
Chapter 3. Tuned
3.1. Tuned Overview
Tuned is a daemon that uses
udevto 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 modeis 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
daemon = 0.
Static tuning mainly consists of the application of predefined
sysfssettings 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.conffile and changing the
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
governorparameter 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_thresholdparameter, the latency is set to the value specified by the
latency_highparameter, 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_latencyparameter 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_powersaveparameter, the plugin sets the FSB speed to the value specified by the
she_powersaveparameter (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_normalparameter, it sets the FSB speed to the value specified by the
she_normalparameter. 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_lanparameter (it uses same syntax as the ethtool utility). It also dynamically changes the interface speed according to the interface utilization.
- Sets various
sysctlsettings specified by the plugin parameters. The syntax is
nameis 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
autosuspendparameter. The value 0 means that autosuspend is disabled.
- Enables or disables transparent huge pages depending on the Boolean value of the
- Sets the autosuspend timeout for audio codecs to the value specified by the
snd_ac97_codecare supported. The value
0means that the autosuspend is disabled. You can also enforce the controller reset by setting the Boolean parameter
- Sets the elevator to the value specified by the
elevatorparameter. It also sets ALPM to the value specified by the
alpmparameter, ASPM to the value specified by the
aspmparameter, scheduler quantum to the value specified by the
scheduler_quantumparameter, disk spindown timeout to the value specified by the
spindownparameter, disk readahead to the value specified by the
readaheadparameter, and can multiply the current disk readahead value by the constant specified by the
readahead_multiplyparameter. 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
dynamicand is enabled by default.
NoteApplying a tuned profile which stipulates a different disk readahead value overrides the disk readahead value settings if they have been configured using a
udevrule. Red Hat recommends using the tuned tool to adjust the disk readahead values.
- Enables or disables barriers for mounts according to the Boolean value of the
- 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
stop(it depends on whether the script is called during the profile load or unload). The script file name can be specified by the
scriptparameter. 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
functionsBash 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
sysfssettings specified by the plugin parameters. The syntax is
sysfspath 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_powersaveparameter. Supported values are:
dynpm. For details, refer to http://www.x.org/wiki/RadeonFeature#KMS_Power_Management_Options. Note that this plugin is experimental and the parameter may change in the future releases.
- Adds parameters to the kernel boot command line. This plugin supports the legacy GRUB 1, GRUB 2, and also GRUB with Extensible Firmware Interface (EFI). Customized non-standard location of the grub2 configuration file can be specified by the
grub2_cfg_fileoption. 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
powersaveprofile (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:
To view the currently activated profile, run:
To select or activate a profile, run:
tuned-adm profile profile
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
highthroughput by using the
throughput-performanceprofile and concurrently setting the disk spindown to the
lowvalue by the
spindown-diskprofile. 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 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:
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
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.
tuned.conffile 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.
[main]section has the following option:
- The specified profile will be included, e.g.
include=powersavewill include the
Sections describing plugins instances are formatted in the following way:
[NAME] type=TYPE devices=DEVICES
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
devicesline can contain a list, a wildcard (*), and negation (!). You can also combine rules. If there is no
devicesline all devices present or later attached on the system of the
TYPEwill 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 Plug-ins Instances
The following example will match everything starting with
sd, such as
sdb, and does not disable barriers on them:
[data_disk] type=disk devices=sd* disable_barriers=false
The following example will match everything except
[data_disk] type=disk devices=!sda1, !sda2 disable_barriers=false
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
typeline. The instance will then be referred to with a name, same as the type. The previous example could be then rewritten into:
[disk] devices=sdb* disable_barriers=false
If the same section is specified more than once using the
includeoption, 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
replaceboolean 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=falseoption. 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
includeoption and do not want the plugin to be active in your custom profile.
The following is an example of a custom profile that is based on the
balancedprofile and extends it the way that ALPM for all devices is set to the maximal powersaving.
[main] include=balanced [disk] alpm=min_power
The following is an example of a custom profile that adds
isolcpus=2to the kernel boot command line:
The machine needs to be rebooted after the profile is applied for the changes to take effect.
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-admutility. You can also create, modify, and delete profiles.
To list all available profiles and identify the current active profile, run:
To only display the currently active profile, run:
To switch to one of the available profiles, run:
tuned-adm profile profile_name
tuned-adm profile latency-performance
To disable all tuning:
The following is a list of pre-defined profiles for typical use cases:
The following profiles may or may not be installed with the base package, depending on the repo files being used. To see the tuned profiles installed on your system, run the following command as root:
To see the list of available tuned profiles to install, run the following command as root:
yum search tuned-profiles
To install a tuned profile on your system, run the following command as root:
yum install tuned-profiles-profile-name
Replacing profile-name with the profile you want to install.
- The default power-saving profile. It is intended to be a compromise between performance and power consumption. It tries to use auto-scaling and auto-tuning 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
radeon_powersaveis set to
- 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
ondemandgovernor. 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.
powersaveprofile 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
balancedprofile 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
deadlinescheduler. CPU governor is set to
- 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
performanceand 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-performanceprofile. 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-performanceprofile. It additionally increases kernel network buffers.
- A profile designed for Red Hat Enterprise Linux 7 virtual machines as well as VMware 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-storageprofile that, among other tasks, decreases virtual memory swappiness, increases disk readahead values and enables a more aggressive value of dirty pages.
- A profile optimized for Oracle databases loads based on
throughput-performanceprofile. It additionally 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
balancedprofile. It additionally enables scheduler autogroups for better response of interactive applications.
cpu-partitioningprofile partitions the system CPUs into isolated and housekeeping CPUs. To reduce jitter and interruptions on an isolated CPU, the profile clears the isolated CPU from user-space processes, movable kernel threads, interrupt handlers, and kernel timers.A housekeeping CPU can run all services, shell processes, and kernel threads.You can configure the
cpu-partitioningprofile in the
/etc/tuned/cpu-partitioning-variables.conffile. The configuration options are:
For more information on
- Lists CPUs to isolate. The list of isolated CPUs is comma-separated or the user can specify the range. You can specify a range using a dash, such as
3-5. This option is mandatory. Any CPU missing from this list is automatically considered a housekeeping CPU.
- Lists CPUs which are not considered by the kernel during system wide process load-balancing. This option is optional. This is usually the same list as
cpu-partitioning, see the tuned-profiles-cpu-partitioning(7) man page.
There may be more product specific or third 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
Optionalchannel. 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
- 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
- A server profile directed at enterprise-class storage, maximizing I/O throughput. It activates the same settings as the
throughput-performanceprofile, multiplies readahead settings, and disables barriers on non-root and non-boot partitions.
atomic-hostprofile on physical machines, and the
atomic-guestprofile 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 third-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:
To enable the
realtimeprofile, install the tuned-profiles-realtime package. Run, as root, the following command:
yum install tuned-profiles-realtime
To enable the
realtime-virtual-guestprofiles, install the tuned-profiles-nfv package. Run, as root, the following command:
yum install tuned-profiles-nfv
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:
By default it creates the profile in the
/etc/tuneddirectory 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
-eoption 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: