This documentation explains how to use the TuneD application to monitor and optimize the throughput, latency, and power consumption of your system in different scenarios.
Getting started with TuneD
As a system administrator, you can use the TuneD application to optimize the performance profile of your system for a variety of use cases.
The purpose of TuneD
TuneD is a service that monitors your system and optimizes the performance under certain workloads. The core of TuneD are profiles, which tune your system for different use cases.
TuneD is distributed with a number of predefined profiles for use cases such as:
-
High throughput
-
Low latency
-
Saving power
It is possible to modify the rules defined for each profile and customize how to tune a particular device. When you switch to another profile or deactivate TuneD, all changes made to the system settings by the previous profile revert back to their original state.
You can also configure TuneD to react to changes in device usage and adjusts settings to improve performance of active devices and reduce power consumption of inactive devices.
TuneD profiles
A detailed analysis of a system can be very time-consuming. TuneD provides a number of predefined profiles for typical use cases. You can also create, modify, and delete profiles.
The profiles provided with TuneD are divided into the following categories:
-
Power-saving profiles
-
Performance-boosting profiles
The performance-boosting profiles include profiles that focus on the following aspects:
-
Low latency for storage and network
-
High throughput for storage and network
-
Virtual machine performance
-
Virtualization host performance
Syntax of profile configuration
The tuned.conf
file can contain one [main]
section and other sections for configuring plug-in instances. However, all sections are optional.
Lines starting with the hash sign (#
) are comments.
-
tuned.conf(5)
man page.
The default TuneD profile
During the installation, the best profile for your system is selected automatically. Currently, the default profile is selected according to the following customizable rules:
Environment | Default profile | Goal |
---|---|---|
Compute nodes |
|
The best throughput performance |
Virtual machines |
|
The best performance. If you are not interested in the best performance, you can change it to the |
Other cases |
|
Balanced performance and power consumption |
-
tuned.conf(5)
man page.
Merged TuneD profiles
As an experimental feature, it is possible to select more profiles at once. TuneD will try to merge them during the load.
If there are conflicts, the settings from the last specified profile takes precedence.
The following example optimizes the system to run in a virtual machine for the best performance and concurrently tunes it for low power consumption, while the low power consumption is the priority:
# tuned-adm profile virtual-guest powersave
Warning
|
Merging is done automatically without checking whether the resulting combination of parameters makes sense. Consequently, the feature might tune some parameters the opposite way, which might be counterproductive: for example, setting the disk for high throughput by using the throughput-performance profile and concurrently setting the disk spindown to the low value by the spindown-disk profile.
|
-
tuned.conf(5)
man page.
The location of TuneD profiles
TuneD stores profiles in the following directories:
/usr/lib/tuned/profiles/
-
Distribution-specific profiles are stored in the
/usr/lib/tuned/profiles/
directory. Each profile has its own directory. The profile consists of the main configuration file calledtuned.conf
, and optionally other files, for example helper scripts. /etc/tuned/profiles/
-
If you need to customize a profile, copy the profile directory into the
/etc/tuned/profiles/
directory, which is used for custom profiles, and then adjust it. If there is a system profile and a custom profile of the same name, the custom profile located in/etc/tuned/profiles
is used.
If you want to make TuneD load profiles from a directory other than /usr/lib/tuned/profiles/
and /etc/tuned/profiles/
, you can list it in /etc/tuned/tuned-main.conf
as follows:
profile_dirs=/usr/lib/tuned/profiles,/etc/tuned/profiles,/my/custom/profiles
In this example, profiles are loaded also from /my/custom/profiles/
. If two directories contain profiles with the same names, the one that is listed later takes precedence.
-
tuned.conf(5)
man page.
TuneD profiles distributed with RHEL
The following is a list of profiles that are installed with TuneD on Red Hat Enterprise Linux.
Note
|
There might be more product-specific or third-party TuneD profiles available. Such profiles are usually provided by separate RPM packages. |
balanced
-
The default power-saving profile. It is intended to be a compromise between performance and power consumption. It uses auto-scaling and auto-tuning whenever possible. The only drawback is the increased latency. In the current TuneD release, it enables the CPU, disk, audio, and video plugins, and activates the
conservative
CPU governor. Theradeon_powersave
option uses thedpm-balanced
value if it is supported, otherwise it is set toauto
.It changes the
energy_performance_preference
attribute to thenormal
energy setting. It also changes thescaling_governor
policy attribute to either theconservative
orpowersave
CPU governor. powersave
-
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 Aggressive Link Power Management (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. If your system contains a supported Radeon graphics card with enabled KMS, the profile configures it to automatic power saving. On ASUS Eee PCs, a dynamic Super Hybrid Engine is enabled.It changes the
energy_performance_preference
attribute to thepowersave
orpower
energy setting. It also changes thescaling_governor
policy attribute to either theondemand
orpowersave
CPU governor.NoteIn certain cases, the
balanced
profile is more efficient compared to thepowersave
profile.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 might consume less energy if the transcoding is done on the full power, because the task is finished quickly, the machine starts to idle, and it 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 consumes less power during the transcoding, but the process takes longer and the overall consumed energy can be higher.
That is why the
balanced
profile can be generally a better option. throughput-performance
-
A server profile optimized for high throughput. It disables power savings mechanisms and enables
sysctl
settings that improve the throughput performance of the disk and network IO. CPU governor is set toperformance
.It changes the
energy_performance_preference
andscaling_governor
attribute to theperformance
profile. accelerator-performance
-
The
accelerator-performance
profile contains the same tuning as thethroughput-performance
profile. Additionally, it locks the CPU to low C states so that the latency is less than 100us. This improves the performance of certain accelerators, such as GPUs. latency-performance
-
A server profile optimized for low latency. It disables power savings mechanisms and enables
sysctl
settings that improve latency. CPU governor is set toperformance
and the CPU is locked to the low C states (by PM QoS).It changes the
energy_performance_preference
andscaling_governor
attribute to theperformance
profile. network-latency
-
A profile for low latency network tuning. It is based on the
latency-performance
profile. It additionally disables transparent huge pages and NUMA balancing, and tunes several other network-relatedsysctl
parameters.It inherits the
latency-performance
profile which changes theenergy_performance_preference
andscaling_governor
attribute to theperformance
profile. hpc-compute
-
A profile optimized for high-performance computing. It is based on the
latency-performance
profile. network-throughput
-
A profile for throughput network tuning. It is based on the
throughput-performance
profile. It additionally increases kernel network buffers.It inherits either the
latency-performance
orthroughput-performance
profile, and changes theenergy_performance_preference
andscaling_governor
attribute to theperformance
profile. virtual-guest
-
A profile designed for virtual guests based on the
throughput-performance
profile that, among other tasks, decreases virtual memory swappiness and increases disk readahead values. It does not disable disk barriers.It inherits the
throughput-performance
profile and changes theenergy_performance_preference
andscaling_governor
attribute to theperformance
profile. virtual-host
-
A profile designed for virtual hosts based on the
throughput-performance
profile that, among other tasks, decreases virtual memory swappiness, increases disk readahead values, and enables a more aggressive value of dirty pages writeback.It inherits the
throughput-performance
profile and changes theenergy_performance_preference
andscaling_governor
attribute to theperformance
profile. oracle
-
A profile optimized for Oracle databases loads based on
throughput-performance
profile. It additionally disables transparent huge pages and modifies other performance-related kernel parameters. This profile is provided by thetuned-profiles-oracle
package. desktop
-
A profile optimized for desktops, based on the
balanced
profile. It additionally enables scheduler autogroups for better response of interactive applications. cpu-partitioning
-
The
cpu-partitioning
profile 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-partitioning
profile in/etc/tuned/cpu-partitioning-variables.conf
file. The configuration options are:isolated_cores=cpu-list
-
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. no_balance_cores=cpu-list
-
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
isolated_cores
.
For more information on
cpu-partitioning
, see thetuned-profiles-cpu-partitioning(7)
man page. optimize-serial-console
-
A profile that tunes down I/O activity to the serial console by reducing the printk value. This should make the serial console more responsive. This profile is intended to be used as an overlay on other profiles. For example:
# tuned-adm profile throughput-performance optimize-serial-console
mssql
-
A profile provided for Microsoft SQL Server. It is based on the
thoguhput-performance
profile. postgresql
-
A profile optimized for PostgreSQL databases loads based on
throughput-performance
profile. It additionally disables transparent huge pages and modifies other performance-related kernel parameters. This profile is provided by thetuned-profiles-postgresql
package. intel-sst
-
A profile optimized for systems with user-defined Intel Speed Select Technology configurations. This profile is intended to be used as an overlay on other profiles. For example:
# tuned-adm profile cpu-partitioning intel-sst
Real-time TuneD profiles distributed with RHEL
Real-time profiles are intended for systems running the real-time kernel. Without a special kernel build, they do not configure the system to be real-time. On RHEL, the profiles are available from additional repositories.
The following real-time profiles are available:
realtime
-
Use on bare-metal real-time systems.
Provided by the
tuned-profiles-realtime
package, which is available from the RT or NFV repositories. realtime-virtual-host
-
Use in a virtualization host configured for real-time.
Provided by the
tuned-profiles-nfv-host
package, which is available from the NFV repository. realtime-virtual-guest
-
Use in a virtualization guest configured for real-time.
Provided by the
tuned-profiles-nfv-guest
package, which is available from the NFV repository.
Static and dynamic tuning in TuneD
This section explains the difference between the two categories of system tuning that TuneD applies: static and dynamic.
- Static tuning
-
Mainly consists of the application of predefined
sysctl
andsysfs
settings and one-shot activation of several configuration tools such asethtool
. - Dynamic tuning
-
Watches how various system components are used throughout the uptime of your system. TuneD adjusts system settings dynamically based on that monitoring information.
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.
By default, dynamic tuning is disabled. To enable it, edit the
/etc/tuned/tuned-main.conf
file and change thedynamic_tuning
option to1
. TuneD then periodically analyzes system statistics and uses them to update your system tuning settings. To configure the time interval in seconds between these updates, use theupdate_interval
option.Currently implemented dynamic tuning algorithms try to balance the performance and powersave, and are therefore disabled in the performance profiles. Dynamic tuning for individual plug-ins can be enabled or disabled in the TuneD profiles.
On a typical office workstation, the Ethernet network interface is inactive most of the time. Only a few emails go in and out 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 high.
This principle is used for other plug-ins for CPU and disks as well.
TuneD no-daemon mode
You can run TuneD in no-daemon
mode, which does not require any resident memory. In this mode, TuneD applies the settings and exits.
By default, no-daemon
mode is disabled because a lot of TuneD functionality is missing in this mode, including:
-
D-Bus support
-
Hot-plug support
-
Rollback support for settings
To enable no-daemon
mode, include the following line in the /etc/tuned/tuned-main.conf
file:
daemon = 0
Installing and enabling TuneD
This procedure installs and enables the TuneD application, installs TuneD profiles, and presets a default TuneD profile for your system.
-
Install the
tuned
package:# yum install tuned
-
Enable and start the
tuned
service:# systemctl enable --now tuned
-
Optionally, install TuneD profiles for real-time systems:
# yum install tuned-profiles-realtime tuned-profiles-nfv
-
Verify that a TuneD profile is active and applied:
$ tuned-adm active Current active profile: balanced
$ tuned-adm verify Verification succeeded, current system settings match the preset profile. See TuneD log file ('/var/log/tuned/tuned.log') for details.
Listing available TuneD profiles
This procedure lists all TuneD profiles that are currently available on your system.
-
To list all available TuneD profiles on your system, use:
$ tuned-adm list Available profiles: - balanced - General non-specialized tuned profile - desktop - Optimize for the desktop use-case - latency-performance - Optimize for deterministic performance at the cost of increased power consumption - network-latency - Optimize for deterministic performance at the cost of increased power consumption, focused on low latency network performance - network-throughput - Optimize for streaming network throughput, generally only necessary on older CPUs or 40G+ networks - powersave - Optimize for low power consumption - throughput-performance - Broadly applicable tuning that provides excellent performance across a variety of common server workloads - virtual-guest - Optimize for running inside a virtual guest - virtual-host - Optimize for running KVM guests Current active profile: balanced
-
To display only the currently active profile, use:
$ tuned-adm active Current active profile: balanced
-
The
tuned-adm(8)
man page.
Setting a TuneD profile
This procedure activates a selected TuneD profile on your system.
-
The
tuned
service is running. See Installing and Enabling Tuned for details.
-
Optionally, you can let TuneD recommend the most suitable profile for your system:
# tuned-adm recommend balanced
-
Activate a profile:
# tuned-adm profile selected-profile
Alternatively, you can activate a combination of multiple profiles:
# tuned-adm profile profile1 profile2
Example 4. A virtual machine optimized for low power consumptionThe following example optimizes the system to run in a virtual machine with the best performance and concurrently tunes it for low power consumption, while the low power consumption is the priority:
# tuned-adm profile virtual-guest powersave
-
View the current active TuneD profile on your system:
# tuned-adm active Current active profile: selected-profile
-
Reboot the system:
# reboot
-
Verify that the TuneD profile is active and applied:
$ tuned-adm verify Verification succeeded, current system settings match the preset profile. See TuneD log file ('/var/log/tuned/tuned.log') for details.
-
tuned-adm(8)
man page
Disabling TuneD
This procedure disables TuneD and resets all affected system settings to their original state before TuneD modified them.
-
To disable all tunings temporarily:
# tuned-adm off
The tunings are applied again after the
tuned
service restarts. -
Alternatively, to stop and disable the
tuned
service permanently:# systemctl disable --now tuned
-
tuned-adm(8)
man page
Related information
-
The
tuned(8)
man page -
The
tuned-adm(8)
man page -
The TuneD project website: https://tuned-project.org/
Customizing TuneD profiles
You can create or modify TuneD profiles to optimize system performance for your intended use case.
-
Install and enable TuneD as described in Installing and Enabling Tuned for details.
TuneD profiles
A detailed analysis of a system can be very time-consuming. TuneD provides a number of predefined profiles for typical use cases. You can also create, modify, and delete profiles.
The profiles provided with TuneD are divided into the following categories:
-
Power-saving profiles
-
Performance-boosting profiles
The performance-boosting profiles include profiles that focus on the following aspects:
-
Low latency for storage and network
-
High throughput for storage and network
-
Virtual machine performance
-
Virtualization host performance
Syntax of profile configuration
The tuned.conf
file can contain one [main]
section and other sections for configuring plug-in instances. However, all sections are optional.
Lines starting with the hash sign (#
) are comments.
-
tuned.conf(5)
man page.
The default TuneD profile
During the installation, the best profile for your system is selected automatically. Currently, the default profile is selected according to the following customizable rules:
Environment | Default profile | Goal |
---|---|---|
Compute nodes |
|
The best throughput performance |
Virtual machines |
|
The best performance. If you are not interested in the best performance, you can change it to the |
Other cases |
|
Balanced performance and power consumption |
-
tuned.conf(5)
man page.
Merged TuneD profiles
As an experimental feature, it is possible to select more profiles at once. TuneD will try to merge them during the load.
If there are conflicts, the settings from the last specified profile takes precedence.
The following example optimizes the system to run in a virtual machine for the best performance and concurrently tunes it for low power consumption, while the low power consumption is the priority:
# tuned-adm profile virtual-guest powersave
Warning
|
Merging is done automatically without checking whether the resulting combination of parameters makes sense. Consequently, the feature might tune some parameters the opposite way, which might be counterproductive: for example, setting the disk for high throughput by using the throughput-performance profile and concurrently setting the disk spindown to the low value by the spindown-disk profile.
|
-
tuned.conf(5)
man page.
The location of TuneD profiles
TuneD stores profiles in the following directories:
/usr/lib/tuned/profiles/
-
Distribution-specific profiles are stored in the
/usr/lib/tuned/profiles/
directory. Each profile has its own directory. The profile consists of the main configuration file calledtuned.conf
, and optionally other files, for example helper scripts. /etc/tuned/profiles/
-
If you need to customize a profile, copy the profile directory into the
/etc/tuned/profiles/
directory, which is used for custom profiles, and then adjust it. If there is a system profile and a custom profile of the same name, the custom profile located in/etc/tuned/profiles
is used.
If you want to make TuneD load profiles from a directory other than /usr/lib/tuned/profiles/
and /etc/tuned/profiles/
, you can list it in /etc/tuned/tuned-main.conf
as follows:
profile_dirs=/usr/lib/tuned/profiles,/etc/tuned/profiles,/my/custom/profiles
In this example, profiles are loaded also from /my/custom/profiles/
. If two directories contain profiles with the same names, the one that is listed later takes precedence.
-
tuned.conf(5)
man page.
Inheritance between TuneD profiles
TuneD profiles can be based on other profiles and modify only certain aspects of their parent profile.
The [main]
section of TuneD profiles recognizes the include
option:
[main] include=parent
All settings from the parent profile are loaded in this child profile. In the following sections, the child profile can override certain settings inherited from the parent profile or add new settings not present in the parent profile.
You can create your own child profile in the /etc/tuned/profiles/
directory based on a pre-installed profile in /usr/lib/tuned/profiles/
with only some parameters adjusted.
If the parent profile is updated, such as after a TuneD upgrade, the changes are reflected in the child profile.
The following is an example of a custom profile that extends the balanced
profile and sets Aggressive Link Power Management (ALPM) for all devices to the maximum powersaving.
[main] include=balanced [scsi_host] alpm=min_power
-
tuned.conf(5)
man page
Static and dynamic tuning in TuneD
This section explains the difference between the two categories of system tuning that TuneD applies: static and dynamic.
- Static tuning
-
Mainly consists of the application of predefined
sysctl
andsysfs
settings and one-shot activation of several configuration tools such asethtool
. - Dynamic tuning
-
Watches how various system components are used throughout the uptime of your system. TuneD adjusts system settings dynamically based on that monitoring information.
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.
By default, dynamic tuning is disabled. To enable it, edit the
/etc/tuned/tuned-main.conf
file and change thedynamic_tuning
option to1
. TuneD then periodically analyzes system statistics and uses them to update your system tuning settings. To configure the time interval in seconds between these updates, use theupdate_interval
option.Currently implemented dynamic tuning algorithms try to balance the performance and powersave, and are therefore disabled in the performance profiles. Dynamic tuning for individual plug-ins can be enabled or disabled in the TuneD profiles.
On a typical office workstation, the Ethernet network interface is inactive most of the time. Only a few emails go in and out 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 high.
This principle is used for other plug-ins for CPU and disks as well.
TuneD plug-ins
Plug-ins are modules in TuneD profiles that TuneD uses to monitor or optimize different devices on the system.
TuneD uses two types of plug-ins:
- Monitoring plug-ins
-
Monitoring plug-ins are used to get information from a running system. The output of the monitoring plug-ins can be used by tuning plug-ins for dynamic tuning.
Monitoring plug-ins are automatically instantiated whenever their metrics are needed by any of the enabled tuning plug-ins. If two tuning plug-ins require the same data, only one instance of the monitoring plug-in is created and the data is shared.
- Tuning plug-ins
-
Each tuning plug-in tunes an individual subsystem and takes several parameters that are populated from the TuneD profiles. Each subsystem can have multiple devices, such as multiple CPUs or network cards, that are handled by individual instances of the tuning plug-ins. Specific settings for individual devices are also supported.
Syntax for plug-ins in TuneD profiles
Sections describing plug-in instances are formatted in the following way:
[NAME] type=TYPE devices=DEVICES
- NAME
-
is the name of the plug-in instance as it is used in the logs. It can be an arbitrary string.
- TYPE
-
is the type of the tuning plug-in.
- DEVICES
-
is the list of devices that this plug-in instance handles.
The
devices
line can contain a list, a wildcard (*
), and negation (!
). If there is nodevices
line, all devices present or later attached on the system of the TYPE are handled by the plug-in instance. This is same as using thedevices=*
option.Example 9. Matching block devices with a plug-inThe following example matches all block devices starting with
sd
, such assda
orsdb
, and does not disable barriers on them:[data_disk] type=disk devices=sd* disable_barriers=false
The following example matches all block devices except
sda1
andsda2
:[data_disk] type=disk devices=!sda1, !sda2 disable_barriers=false
If no instance of a plug-in is specified, the plug-in is not enabled.
If the plug-in supports more options, they can be also specified in the plug-in section. If the option is not specified and it was not previously specified in the included plug-in, the default value is used.
Short plug-in syntax
If you do not need custom names for the plug-in instance and there is only one definition of the instance in your configuration file, TuneD supports the following short syntax:
[TYPE] devices=DEVICES
In this case, it is possible to omit the type
line. The instance is then referred to with a name, same as the type. The previous example could be then rewritten into:
[disk] devices=sdb* disable_barriers=false
Conflicting plug-in definitions in a profile
If the same section is specified more than once using the include
option, the settings are merged. If they cannot be merged due to a conflict, the last conflicting definition overrides the previous settings. If you do not know what was previously defined, you can use the replace
Boolean option and set it to true
. This causes all the previous definitions with the same name to be overwritten and the merge does not happen.
You can also disable the plug-in by specifying the enabled=false
option. This has the same effect as if the instance was never defined. Disabling the plug-in is useful if you are redefining the previous definition from the include
option and do not want the plug-in to be active in your custom profile.
- NOTE
-
TuneD includes the ability to run any shell command as part of enabling or disabling a tuning profile. This enables you to extend TuneD profiles with functionality that has not been integrated into TuneD yet.
You can specify arbitrary shell commands using the
script
plug-in.
-
tuned.conf(5)
man page
Available TuneD plug-ins
This section lists all monitoring and tuning plug-ins currently available in TuneD.
acpi
Configures the ACPI driver.
The only currently supported option is
platform_profile
, which sets the ACPI
platform profile sysfs attribute,
a generic power/performance preference API for other drivers.
Multiple profiles can be specified, separated by |
.
The first available profile is selected.
[acpi] platform_profile=balanced|low-power
Using this option, TuneD will try to set the platform profile
to balanced
. If that fails, it will try to set it to low-power
.
audio
Sets audio cards power saving options. The plug-in sets the auto suspend
timeout for audio codecs to the value specified by the timeout
option.
Currently, the snd_hda_intel
and snd_ac97_codec
codecs are
supported and the timeout
value is in seconds. To disable
auto suspend for these codecs, set the timeout
value
to 0
. To enforce the controller reset, set the option
reset_controller
to true
. Note that power management
is supported per module. Hence, the kernel module names are used as
device names.
[audio] timeout=10 reset_controller=true
bootloader
Adds options to the kernel command line. This plug-in supports the GRUB 2 boot loader and the Boot Loader Specification (BLS).
Note
|
TuneD will not remove or replace kernel command line parameters added via other methods like grubby. TuneD will manage the kernel command line parameters added via TuneD. Please refer to your platform bootloader documentation about how to identify and manage kernel command line parameters set outside of TuneD. |
Customized non-standard location of the GRUB 2 configuration file
can be specified by the grub2_cfg_file
option.
The kernel options are added to the current GRUB configuration and its templates. Reboot the system for the kernel option to take effect.
Switching to another profile or manually stopping the tuned
service removes the additional options. If you shut down or reboot
the system, the kernel options persist in the grub.cfg
file and grub environment files.
The kernel options can be specified by the following syntax:
cmdlinesuffix=arg1 arg2 ... argN
Or with an alternative, but equivalent syntax:
cmdlinesuffix=+arg1 arg2 ... argN
Where suffix can be arbitrary (even empty) alphanumeric
string which should be unique across all loaded profiles. It is
recommended to use the profile name as the suffix
(for example, cmdline_my_profile
). If there are multiple
cmdline
options with the same suffix, during the profile
load/merge the value which was assigned previously will be used. This
is the same behavior as any other plug-in options. The final kernel
command line is constructed by concatenating all the resulting
cmdline
options.
It is also possible to remove kernel options by the following syntax:
cmdlinesuffix=-arg1 arg2 ... argN
Such kernel options will not be concatenated and thus removed during the final kernel command line construction.
For example, to add the quiet
kernel option to a TuneD
profile, include the following lines in the tuned.conf
file:
[bootloader] cmdline_my_profile=+quiet
An example of a custom profile my_profile
that adds the
isolcpus=2
option to the kernel command line:
[bootloader] cmdline_my_profile=isolcpus=2
An example of a custom profile my_profile
that removes the
rhgb quiet
options from the kernel command line (if
previously added by TuneD):
[bootloader] cmdline_my_profile=-rhgb quiet
For example, to add the rhgb quiet
kernel options to a
TuneD profile profile_1
:
[bootloader] cmdline_profile_1=+rhgb quiet
In the child profile profile_2
drop the quiet
option
from the kernel command line:
[main] include=profile_1 [bootloader] cmdline_profile_2=-quiet
The final kernel command line will be rhgb
. In case the same
cmdline
suffix as in the profile_1
is used:
[main] include=profile_1 [bootloader] cmdline_profile_1=-quiet
It will result in the empty kernel command line because the merge
executes and the cmdline_profile_1
gets redefined to just
-quiet
. Thus there is nothing to remove in the final kernel
command line processing.
The initrd_add_img=IMAGE
adds an initrd overlay file
IMAGE
. If the IMAGE
file name begins with '/', the absolute path is
used. Otherwise, the current profile directory is used as the base
directory for the IMAGE
.
The initrd_add_dir=DIR
creates an initrd image from the
directory DIR
and adds the resulting image as an overlay.
If the DIR
directory name begins with '/', the absolute path
is used. Otherwise, the current profile directory is used as the
base directory for the DIR
.
The initrd_dst_img=PATHNAME
sets the name and location of
the resulting initrd image. Typically, it is not necessary to use this
option. By default, the location of initrd images is /boot
and the
name of the image is taken as the basename of IMAGE
or DIR
. This can
be overridden by setting initrd_dst_img
.
The initrd_remove_dir=VALUE
removes the source directory
from which the initrd image was built if VALUE
is true. Only 'y',
'yes', 't', 'true' and '1' (case insensitive) are accepted as true
values for this option. Other values are interpreted as false.
[bootloader] initrd_remove_dir=True initrd_add_dir=/tmp/tuned-initrd.img
This creates an initrd image from the /tmp/tuned-initrd.img
directory
and and then removes the tuned-initrd.img
directory from /tmp
.
The skip_grub_config=VALUE
does not change grub
configuration if VALUE
is true. However, cmdline
options are still processed, and the result is used to verify the current
cmdline. Only 'y', 'yes', 't', 'true' and '1' (case insensitive) are accepted
as true values for this option. Other values are interpreted as false.
[bootloader] skip_grub_config=True cmdline=+systemd.cpu_affinity=1
cpu
Sets the CPU governor to the value specified by the governor
option and dynamically changes the Power Management Quality of
Service (PM QoS) CPU Direct Memory Access (DMA) latency according
to the CPU load.
governor
-
The
governor
option of the 'cpu' plug-in supports specifying CPU governors. Multiple governors are separated using '|'. The '|' character is meant to represent a logical 'or' operator. Note that the same syntax is used for theenergy_perf_bias
option. TuneD will set the first governor that is available on the system.Example 17. Specifying a CPU governor[cpu] governor=ondemand|powersave
TuneD will set the 'ondemand' governor, if it is available. If it is not available, but the 'powersave' governor is available, 'powersave' will be set. If neither of them are available, the governor will not be changed.
sampling_down_factor
-
The sampling rate determines how frequently the governor checks to tune the CPU. The
sampling_down_factor
is a tunable that multiplies the sampling rate when the CPU is at its highest clock frequency thereby delaying load evaluation and improving performance. Allowed values for sampling_down_factor are 1 to 100000.Example 18. The recommended setting for jitter reduction[cpu] sampling_down_factor = 100
energy_perf_bias
-
energy_perf_bias
supports managing energy vs. performance policy via x86 Model Specific Registers using thex86_energy_perf_policy
tool. Multiple alternative Energy Performance Bias (EPB) values are supported. The alternative values are separated using the '|' character. The following EPB values are supported starting with kernel 4.13: "performance", "balance-performance", "normal", "balance-power" and "power". On newer processors is value writen straight to file (see rhbz#2095829)Example 19. Specifying alternative Energy Performance Bias values[cpu] energy_perf_bias=powersave|power
TuneD will try to set EPB to 'powersave'. If that fails, it will try to set it to 'power'.
energy_performance_preference
-
energy_performance_preference
supports managing energy vs. performance hints on newer Intel and AMD processors with active P-State CPU scaling drivers (intel_pstate or amd-pstate). Multiple alternative Energy Performance Preferences (EPP) values are supported. The alternative values are separated using the '|' character. Available values can be found inenergy_performance_available_preferences
file inCPUFreq
policy directory insysfs
. inExample 20. Specifying alternative Energy Performance Hints values[cpu] energy_performance_preference=balance_power|power
TuneD will try to set EPP to 'balance_power'. If that fails, it will try to set it to 'power'.
latency_low, latency_high, load_threshold
-
If the CPU load is lower than the value specified by the
load_threshold
option, the latency is set to the value specified either by thelatency_high
option or by thelatency_low
option. force_latency
-
You can also force the latency to a specific value and prevent it from dynamically changing further. To do so, set the
force_latency
option to the required latency value.The maximum latency value can be specified in several ways:
-
by a numerical value in microseconds (for example,
force_latency=10
) -
as the kernel CPU idle level ID of the maximum C-state allowed (for example, force_latency = cstate.id:1)
-
as a case sensitive name of the maximum C-state allowed (for example, force_latency = cstate.name:C1)
-
by using 'None' as a fallback value to prevent errors when alternative C-state IDs/names do not exist. When 'None' is used in the alternatives pipeline, all the alternatives that follow 'None' are ignored.
It is also possible to specify multiple fallback values separated by '|' as the C-state names and/or IDs may not be available on some systems.
Example 21. Specifying fallback C-state values[cpu] force_latency=cstate.name:C6|cstate.id:4|10
This configuration tries to obtain and set the latency of C-state named C6. If the C-state C6 does not exist, kernel CPU idle level ID 4 (state4) latency is searched for in sysfs. Finally, if the state4 directory in sysfs is not found, the last latency fallback value is
10
us. The value is encoded and written into the kernel’s PM QoS file/dev/cpu_dma_latency
.Example 22. Specifying fallback C-state values using 'None'.[cpu] force_latency=cstate.name:XYZ|None
In this case, if C-state with the name
XYZ
does not exist, no latency value will be written into the kernel’s PM QoS file, and no errors will be reported due to the presence of 'None'. -
min_perf_pct, max_perf_pct, no_turbo
-
These options set the internals of the Intel P-State driver exposed via the kernel’s
sysfs
interface.Example 23. Adjusting the configuration of the Intel P-State driver[cpu] min_perf_pct=100
Limit the minimum P-State that will be requested by the driver. It states it as a percentage of the max (non-turbo) performance level.
pm_qos_resume_latency_us
-
This option allow to set specific latency for all cpus or specific ones.
Example 24. Configuring resume latency[cpu] pm_qos_resume_latency_us=n/a
Special value that disables C-states completely.
[cpu] pm_qos_resume_latency_us=0
Allows all C-states.
[cpu] pm_qos_resume_latency_us=100
Allows any C-state with a resume latency less than 100.
boost
-
The
boost
option allows the CPU to boost above nominal frequencies for shorts periods of time.Example 25. Allowing CPU boost[cpu] boost=1
disk
Plug-in for tuning various block device options. This plug-in can also
dynamically change the advanced power management and spindown timeout
setting for a drive according to the current drive utilization. The
dynamic tuning is controlled by the dynamic
and the global
dynamic_tuning
option in tuned-main.conf
.
The disk plug-in operates on all supported block devices unless a
comma separated list of devices
is passed to it.
sda
block device[disk] devices=sda
The elevator
option sets the Linux I/O scheduler.
xvda
block device[disk] device=xvda elevator=bfq
The scheduler_quantum
option only applies to the CFQ I/O
scheduler. It defines the number of I/O requests that CFQ sends to
one device at one time, essentially limiting queue depth. The default
value is 8 requests. The device being used may support greater queue
depth, but increasing the value of quantum will also increase latency,
especially for large sequential write work loads.
The apm
option sets the Advanced Power Management feature
on drives that support it. It corresponds to using the -B
option of
the hdparm
utility. The spindown
option puts the drive
into idle (low-power) mode, and also sets the standby (spindown)
timeout for the drive. It corresponds to using -S
option of the
hdparm
utility.
[disk] apm=128 spindown=6
The readahead
option controls how much extra data the
operating system reads from disk when performing sequential
I/O operations. Increasing the readahead
value might improve
performance in application environments where sequential reading of
large files takes place. The default unit for readahead is KiB. This
can be adjusted to sectors by specifying the suffix 's'. If the
suffix is specified, there must be at least one space between the
number and suffix (for example, readahead=8192 s
).
readahead
to 4MB unless already set to a higher value[disk] readahead=>4096
The disk readahead value can be multiplied by the constant
specified by the readahead_multiply
option.
eeepc_she
Dynamically sets the front-side bus (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
option, the plug-in sets the FSB speed to the value specified by the
she_powersave
option. If the CPU load is higher or
equal to the value specified by the load_threshold_normal
option, it sets the FSB speed to the value specified by the
she_normal
option. Static tuning is not supported and the
plug-in is transparently disabled if the hardware support for this
feature is not detected.
Note
|
For details about the FSB frequencies and corresponding values, see the kernel documentation. The provided defaults should work for most users. |
irq
Allows tuning of IRQ affinities, and thus re-implements functionality
already present in the scheduler
plugin. However, this plugin offers
more flexibility, as it allows tuning of individual interrupts with
different affinities. When using the irq
plugin, make sure to disable
IRQ processing in the scheduler
plugin by setting its option
irq_process=false
.
The plugin handles individual IRQs as devices and multiple plugin
instances can be defined, each addressing different devices/irqs.
The device names used by the plugin are irq<n>
, where <n>
is the
IRQ number. The special device DEFAULT
controls values written to
/proc/irq/default_smp_affinity
, which applies to all non-active IRQs.
The option affinity
controls the IRQ affinity to be set. It is
a string in "cpulist" format (such as 1,3-4
). If the configured affinity
is empty, then the affinity of the respective IRQs is not touched.
The option mode
is a string which can either be set
(default)
or intersect
. In set
mode the affinity
is always written
as configured, whereas in intersect
mode, the new affinity will be
calculated as the intersection of the current and the configured affinity.
If that intersection is empty, the configured affinity will be used.
[irq_special] type=irq devices=irq16 affinity=2 [irq] affinity=0
irqbalance
Plug-in for irqbalance settings management. The plug-in
configures CPUs which should be skipped when rebalancing IRQs in
/etc/sysconfig/irqbalance
. It then restarts irqbalance if and
only if it was previously running.
The banned/skipped CPUs are specified as a CPU list via the
banned_cpus
option.
[irqbalance] banned_cpus=2,4,9-13
kthread
kthread
-
Allows tuning of kernel threads by setting their CPU affinities and scheduling parameters. The plugin re-implements functionality already present in the
scheduler
plugin. However, this plugin offers more flexibility, as it allows tuning of individual kernel threads, which are handled asdevices
. Multiple plugin instances can be defined, each addressing different groups of kernel threads. When using thekthread
plugin, make sure to disable processing of kernel threads in thescheduler
plugin by setting its optionkthread_process=false
. === Tuning options are controlled bygroup
definitions.A group definition has the form
group.<name> = <rule_prio>:<schedopts>:<affinity>:<regex>
with four required fields:
rule_prio
-
priority of the group within this plugin instance (lower number indicates higher priority)
schedopts
-
desired scheduling policy and priority, or either "*" or an empty string to leave the scheduling options unchanged. The first character defines the policy
-
f: SCHED_FIFO
-
b: SCHED_BATCH
-
r: SCHED_RR
-
o: SCHED_OTHER
-
i: SCHED_IDLE
-
The remainder is the desired priority in the range 0..99. For SCHED_OTHER, only a priority of 0 is allowed. Examples:
f50
to set SCHED_FIFO with priority 50,o0
for SCHED_OTHERaffinity
:: desired affinity (as cpulist string), or either "*" or an empty string to leave the affinity unchangedregex
:: regular expression to match kernel threads. Note that the thread name needs to match the full regex, i.e. matching happens with re.fullmatch().The
group
options of thekthread
plugin differ from those of thescheduler
plugin:-
scheduling policy and priority are combined into one option
-
affinities are specified as cpulist strings instead of masks
-
regular expressions need to fully match the thread names
-
no square brackets are added to the kernel thread names
Example:
The scheduler
definition
group.ksoftirqd=0:f:2:*:^\[ksoftirqd
is translated to the kthread
definition
group.ksoftirqd=0:f2:*:ksoftirqd.*
modules
Plug-in for applying custom kernel modules options.
This plug-in can set parameters to kernel modules. It creates
/etc/modprobe.d/tuned.conf
file. The syntax is
module=option1=value1 option2=value2…
where module
is
the module name and optionx=valuex
are module options which may
or may not be present.
netrom
with module parameter nr_ndevs=2
[modules] netrom=nr_ndevs=2
Modules can also be forced to load/reload by using an additional
+r
option prefix.
netrom
with module parameter nr_ndevs=2
[modules] netrom=+r nr_ndevs=2
The +r
switch will also cause TuneD to try and remove netrom
module (if loaded) and try and (re)insert it with the specified
parameters. The +r
can be followed by an optional comma (+r,
)
for better readability.
When using +r
the module will be loaded immediately by the TuneD
daemon itself rather than waiting for the OS to load it with the
specified parameters.
mounts
Enables or disables barriers for mounts according to the value of the
boolean option disable_barriers
. The option additionally allows
the special value force
, which disables barriers even on mountpoints with
write back caches.
Note
|
Only extended file systems (ext) are supported by this plug-in. |
net
Configures network driver, hardware and Netfilter settings.
Dynamic change of the interface speed according to the interface
utilization is also supported. The dynamic tuning is controlled by
the dynamic
and the global dynamic_tuning
option in tuned-main.conf
.
wake_on_lan
-
The
wake_on_lan
option sets wake-on-lan to the specified value as when using theethtool
utility.Example 34. Set Wake-on-LAN for device eth0 on MagicPacket™[net] devices=eth0 wake_on_lan=g
coalesce
-
The
coalesce
option allows changing coalescing settings for the specified network devices. The syntax is:coalesce=param1 value1 param2 value2 ... paramN valueN
Note that not all the coalescing parameters are supported by all network cards. For the list of coalescing parameters of your network device, use
ethtool -c device
.Example 35. Setting coalescing parameters rx/tx-usecs for all network devices[net] coalesce=rx-usecs 3 tx-usecs 16
features
-
The
features
option allows changing the offload parameters and other features for the specified network devices. To query the features of your network device, useethtool -k device
. The syntax of the option is the same as thecoalesce
option.Example 36. Turn off TX checksumming, generic segmentation and receive offload[net] features=tx off gso off gro off
pause
-
The
pause
option allows changing the pause parameters for the specified network devices. To query the pause parameters of your network device, useethtool -a device
. The syntax of the option is the same as thecoalesce
option.Example 37. Disable autonegotiation[net] pause=autoneg off
ring
-
The
ring
option allows changing the rx/tx ring parameters for the specified network devices. To query the ring parameters of your network device, useethtool -g device
. The syntax of the option is the same as thecoalesce
option.Example 38. Change the number of ring entries for the Rx/Tx rings to 1024/512 respectively[net] ring=rx 1024 tx 512
channels
-
The
channels
option allows changing the numbers of channels for the specified network device. A channel is an IRQ and the set of queues that can trigger that IRQ. To query the channels parameters of your network device, useethtool -l device
. The syntax of the option is the same as thecoalesce
option.Example 39. Set the number of multi-purpose channels to 16[net] channels=combined 16
A network device either supports rx/tx or combined queue mode. The
channels
option automatically adjusts the parameters based on the mode supported by the device as long as a valid configuration is requested. nf_conntrack_hashsize
-
The
nf_conntrack_hashsize
option sets the size of the hash table which stores lists of conntrack entries by writing to/sys/module/nf_conntrack/parameters/hashsize
.Example 40. Adjust the size of the conntrack hash table[net] nf_conntrack_hashsize=131072
txqueuelen
-
The
txqueuelen
option allows changing txqueuelen (the length of the transmit queue). It usesip
utility that is in package iproute recommended for TuneD, so the package needs to be installed for its correct functionality. To query the txqueuelen parameters of your network device useip link show
and the current value is shown after the qlen column.Example 41. Adjust the length of the transmit queue[net] txqueuelen=5000
mtu
-
The
mtu
option allows changing MTU (Maximum Transmission Unit). It usesip
utility that is in package iproute recommended for TuneD, so the package needs to be installed for its correct functionality. To query the MTU parameters of your network device useip link show
and the current value is shown after the MTU column.Example 42. Adjust the size of the MTU[net] mtu=9000
rtentsk
A plug-in for avoiding inter-processor interrupts caused by enabling or disabling static keys.
The plug-in has no options; when included, TuneD will keep an open socket with timestamping enabled, thus keeping the static key enabled.
scheduler
Allows tuning of scheduling priorities, process/thread/IRQ affinities, and CPU isolation.
To prevent processes/threads/IRQs from using certain CPUs, use
the isolated_cores
option. It changes process/thread
affinities, IRQs affinities and it sets default_smp_affinity
for IRQs. The CPU affinity mask is adjusted for all processes and
threads matching ps_whitelist
option subject to success
of the sched_setaffinity()
system call. The default setting of
the ps_whitelist
regular expression is .*
to match all
processes and thread names. To exclude certain processes and threads
use ps_blacklist
option. The value of this option is also
interpreted as a regular expression and process/thread names (ps -eo
cmd
) are matched against that expression. Profile rollback allows
all matching processes and threads to run on all CPUs and restores
the IRQ settings prior to the profile application.
Multiple regular expressions for ps_whitelist
and ps_blacklist
options are allowed and separated by
;
. Quoted semicolon \;
is taken literally.
[scheduler] isolated_cores=2-4 ps_blacklist=.*pmd.*;.*PMD.*;^DPDK;.*qemu-kvm.*
Isolate CPUs 2-4 while ignoring processes and threads matching
ps_blacklist
regular expressions.
The irq_process
option controls whether the scheduler plugin
applies the isolated_cores
parameter to IRQ affinities. The default
value is true
, which means that the scheduler plugin will move all
possible IRQs away from the isolated cores. When irq_process
is set
to false
, the plugin will not change any IRQ affinities.
The default_irq_smp_affinity
option controls the values
TuneD writes to /proc/irq/default_smp_affinity
. The file specifies
default affinity mask that applies to all non-active IRQs. Once an
IRQ is allocated/activated its affinity bitmask will be set to the
default mask.
The following values are supported:
-
calc
The content of
/proc/irq/default_smp_affinity
will be calculated from theisolated_cores
parameter. Non-isolated cores are calculated as an inversion of theisolated_cores
. Then the intersection of the non-isolated cores and the previous content of/proc/irq/default_smp_affinity
is written to/proc/irq/default_smp_affinity
. If the intersection is an empty set, then just the non-isolated cores are written to/proc/irq/default_smp_affinity
. This behavior is the default if the parameterdefault_irq_smp_affinity
is omitted. -
ignore
TuneD will not touch
/proc/irq/default_smp_affinity
. -
an explicit cpulist
The cpulist (such as
1,3-4
) is unpacked and written directly to/proc/irq/default_smp_affinity
.
[scheduler] isolated_cores=1,3 default_irq_smp_affinity=0,2
To adjust scheduling policy, priority and affinity for a group of processes/threads, use the following syntax.
group.groupname=rule_prio:sched:prio:affinity:regex
Here, rule_prio
defines internal TuneD priority of the
rule. Rules are sorted based on priority. This is needed for
inheritence to be able to reorder previously defined rules. Equal
rule_prio
rules should be processed in the order they were
defined. However, this is Python interpreter dependant. To disable
an inherited rule for groupname
use:
group.groupname=
sched
must be one of:
f
for FIFO,
b
for batch,
r
for round robin,
o
for other,
* do not change.
affinity
is CPU affinity in hexadecimal. Use *
for no change.
prio
scheduling priority (see chrt -m
).
regex
is Python regular expression. It is matched against the output of:
ps -eo cmd
Any given process name may match more than one group. In such a case,
the priority and scheduling policy are taken from the last matching
regex
.
[scheduler] group.kthreads=0:*:1:*:\[.*\]$ group.watchdog=0:f:99:*:\[watchdog.*\]
The scheduler plug-in uses perf event loop to catch newly created
processes. By default it listens to perf.RECORD_COMM
and
perf.RECORD_EXIT
events. By setting perf_process_fork
option to true
, perf.RECORD_FORK
events will be also listened
to. In other words, child processes created by the fork()
system
call will be processed. Since child processes inherit CPU affinity
from their parents, the scheduler plug-in usually does not need to
explicitly process these events. As processing perf events can
pose a significant CPU overhead, the perf_process_fork
option parameter is set to false
by default. Due to this, child
processes are not processed by the scheduler plug-in.
The CPU overhead of the scheduler plugin can be mitigated by using
the scheduler runtime
option and setting it to 0
. This
will completely disable the dynamic scheduler functionality and the
perf events will not be monitored and acted upon. The disadvantage
ot this approach is the procees/thread tuning will be done only at
profile application.
[scheduler] runtime=0 isolated_cores=1,3
Note
|
For perf events, memory mapped buffer is used. Under heavy load
the buffer may overflow. In such cases the scheduler plug-in
may start missing events and failing to process some newly created
processes. Increasing the buffer size may help. The buffer size can
be set with the perf_mmap_pages option. The value of this
parameter has to expressed in powers of 2. If it is not the power
of 2, the nearest higher power of 2 value is calculated from it
and this calculated value used. If the perf_mmap_pages
option is omitted, the default kernel value is used.
|
The scheduler plug-in supports process/thread confinement using cgroups v1.
cgroup_mount_point
option specifies the path to mount the
cgroup filesystem or where TuneD expects it to be mounted. If unset,
/sys/fs/cgroup/cpuset
is expected.
If cgroup_groups_init
option is set to 1
TuneD
will create (and remove) all cgroups defined with the cgroup*
options. This is the default behavior. If it is set to 0
the
cgroups need to be preset by other means.
If cgroup_mount_point_init
option is set to 1
,
TuneD will create (and remove) the cgroup mountpoint. It implies
cgroup_groups_init = 1
. If set to 0
the cgroups mount point
needs to be preset by other means. This is the default behavior.
The cgroup_for_isolated_cores
option is the cgroup
name used for the isolated_cores
option functionality. For
example, if a system has 4 CPUs, isolated_cores=1
means that all
processes/threads will be moved to CPUs 0,2-3.
The scheduler plug-in will isolate the specified core by writing
the calculated CPU affinity to the cpuset.cpus
control file of
the specified cgroup and move all the matching processes/threads to
this group. If this option is unset, classic cpuset affinity using
sched_setaffinity()
will be used.
cgroup.cgroup_name
option defines affinities for
arbitrary cgroups. Even hierarchic cgroups can be used, but the
hieararchy needs to be specified in the correct order. Also TuneD
does not do any sanity checks here, with the exception that it forces
the cgroup to be under cgroup_mount_point
.
The syntax of the scheduler option starting with group.
has been
augmented to use cgroup.cgroup_name
instead of the hexadecimal
affinity
. The matching processes will be moved to the cgroup
cgroup_name
. It is also possible to use cgroups which have
not been defined by the cgroup.
option as described above,
i.e. cgroups not managed by TuneD.
All cgroup names are sanitized by replacing all all dots (.
) with
slashes (/
). This is to prevent the plug-in from writing outside
cgroup_mount_point
.
[scheduler] cgroup_mount_point=/sys/fs/cgroup/cpuset cgroup_mount_point_init=1 cgroup_groups_init=1 cgroup_for_isolated_cores=group cgroup.group1=2 cgroup.group2=0,2 group.ksoftirqd=0:f:2:cgroup.group1:ksoftirqd.* ps_blacklist=ksoftirqd.*;rcuc.*;rcub.*;ktimersoftd.* isolated_cores=1
Cgroup group1
has the affinity set to CPU 2 and the cgroup group2
to CPUs 0,2. Given a 4 CPU setup, the isolated_cores=1
option causes all processes/threads to be moved to CPU
cores 0,2-3. Processes/threads that are blacklisted by the
ps_blacklist
regular expression will not be moved.
The scheduler plug-in will isolate the specified core by writing the
CPU affinity 0,2-3 to the cpuset.cpus
control file of the group
and move all the matching processes/threads to this cgroup.
Option cgroup_ps_blacklist
allows excluding processes
which belong to the blacklisted cgroups. The regular expression specified
by this option is matched against cgroup hierarchies from
/proc/PID/cgroups
. Cgroups v1 hierarchies from /proc/PID/cgroups
are separated by commas ',' prior to regular expression matching. The
following is an example of content against which the regular expression
is matched against: 10:hugetlb:/,9:perf_event:/,8:blkio:/
Multiple regular expressions can be separated by semicolon ';'. The semicolon represents a logical 'or' operator.
[scheduler] isolated_cores=1 cgroup_ps_blacklist=:/daemons\b
The scheduler plug-in will move all processes away from core 1 except processes which belong to cgroup '/daemons'. The '\b' is a regular expression metacharacter that matches a word boundary.
[scheduler] isolated_cores=1 cgroup_ps_blacklist=\b8:blkio:
The scheduler plug-in will exclude all processes which belong to a cgroup with hierarchy-ID 8 and controller-list blkio.
Kernels 5.13 and newer moved some sched_
and numa_balancing_
kernel run-time
parameters from /proc/sys/kernel
, managed by the sysctl
utility, to
debugfs
, typically mounted under /sys/kernel/debug
. TuneD provides an
abstraction mechanism for the following parameters via the scheduler plug-in:
sched_min_granularity_ns
, sched_latency_ns
,
sched_wakeup_granularity_ns
, sched_tunable_scaling
,
sched_migration_cost_ns
, sched_nr_migrate
,
numa_balancing_scan_delay_ms
,
numa_balancing_scan_period_min_ms
,
numa_balancing_scan_period_max_ms
and
numa_balancing_scan_size_mb
.
Moreover in kernel 6.6 and newer support for the sched_wakeup_granularity_ns
and
sched_latency_ns
were removed. The sched_min_granularity_ns
was renamed to
sched_base_slice_ns
. Based on the kernel used, TuneD will write the specified
value to the correct location or ignore it. For the compatibility the alias
sched_base_slice_ns
was added, but the sched_min_granularity_ns
can be still used instead.
[scheduler] sched_migration_cost_ns=500000
On the old kernels, this is equivalent to:
[sysctl] kernel.sched_migration_cost_ns=500000
that is, value 500000
will be written to /proc/sys/kernel/sched_migration_cost_ns
.
However, on more recent kernels, the value 500000
will be written to
/sys/kernel/debug/sched/migration_cost_ns
.
script
Executes an external script or binary when the profile is loaded or unloaded. You can choose an arbitrary executable.
Important
|
The script plug-in is provided mainly for compatibility
with earlier releases. Prefer other TuneD plug-ins if they cover
the required functionality.
|
TuneD calls the executable with one of the following arguments:
-
start
when loading the profile -
stop
when unloading the profile
You need to correctly implement the stop
action in your executable
and revert all settings that you changed during the start
action. Otherwise, the roll-back step after changing your TuneD
profile will not work.
Bash scripts can import the /usr/lib/tuned/functions
Bash library and use the functions defined there. Use these
functions only for functionality that is not natively provided
by TuneD. If a function name starts with an underscore, such as
_wifi_set_power_level
, consider the function private and do not
use it in your scripts, because it might change in the future.
Specify the path to the executable using the script
parameter in
the plug-in configuration.
To run a Bash script named script.sh
that is located in the profile
directory, use:
[script] script=${i:PROFILE_DIR}/script.sh
scsi_host
Tunes options for SCSI hosts.
The plug-in sets Aggressive Link Power Management (ALPM) to the value specified
by the alpm
option. The option takes one of three values:
min_power
, medium_power
and max_performance
.
Note
|
ALPM is only available on SATA controllers that use the Advanced Host Controller Interface (AHCI). |
[scsi_host] alpm=min_power
selinux
Plug-in for tuning SELinux options.
SELinux decisions, such as allowing or denying access, are
cached. This cache is known as the Access Vector Cache (AVC). When
using these cached decisions, SELinux policy rules need to be checked
less, which increases performance. The avc_cache_threshold
option allows adjusting the maximum number of AVC entries.
Note
|
Prior to changing the default value, evaluate the system performance with care. Increasing the value could potentially decrease the performance by making AVC slow. |
[selinux] avc_cache_threshold=8192
service
Plug-in for handling sysvinit, sysv-rc, openrc and systemd services.
The syntax is as follows:
[service] service.service_name=commands[,file:file]
Supported service-handling commands
are start
, stop
, enable
and disable
. The optional file:file
directive installs an overlay
configuration file file
. Multiple commands must be comma (,
)
or semicolon (;
) separated. If the directives conflict, the last
one is used.
The service plugin supports configuration overlays only for systemd.
In other init systems, this directive is ignored. The configuration
overlay files are copied to /etc/systemd/system/service_name.service.d/
directories. Upon profile unloading, the directory is removed if it is empty.
With systemd, the start
command is implemented by restart
in order
to allow loading of the service configuration file overlay.
Note
|
With non-systemd init systems, the plug-in operates on the current runlevel only. |
sendmail
service with an overlay file[service] service.sendmail=start,enable,file:${i:PROFILE_DIR}/tuned-sendmail.conf
The internal variable ${i:PROFILE_DIR}
points to the directory
from which the profile is loaded.
sysctl
Sets various kernel parameters at runtime.
This plug-in is used for applying custom sysctl
settings and should
only be used to change system settings that are not covered by other
TuneD plug-ins. If the settings are covered by other TuneD plug-ins,
use those plug-ins instead.
The syntax for this plug-in is
key=value
, where
key
is the same as the key name provided by the
sysctl
utility.
[sysctl] kernel.sched_min_granularity_ns=3000000
sysfs
Sets various sysfs
settings specified by the plug-in options.
The syntax is name=value
, where
name
is the sysfs
path to use and value
is
the value to write. The sysfs
path supports the shell-style
wildcard characters (see man 7 glob
for additional detail).
Use this plugin in case you need to change some settings that are not covered by other plug-ins. Prefer specific plug-ins if they cover the required settings.
[sysfs] /sys/devices/system/machinecheck/machinecheck*/ignore_ce=1
systemd
Plug-in for tuning systemd options.
The cpu_affinity
option allows setting CPUAffinity in
/etc/systemd/system.conf
. This configures the CPU affinity for the
service manager as well as the default CPU affinity for all forked
off processes. The option takes a comma-separated list of CPUs with
optional CPU ranges specified by the minus sign (-
).
systemd
to 0 1 2 3
[systemd] cpu_affinity=0-3
Note
|
These tunings are unloaded only on profile change followed by a reboot. |
uncore
An Intel-specific plug-in for limiting the maximum and minimum uncore frequency.
The options max_freq_khz
, min_freq_khz
correspond to
sysfs
files exposed by Intel uncore frequency driver. Their values can be
specified in kHz or as a percentage of their configurable range.
[uncore10] type=uncore devices=uncore10 max_freq_khz=4000000 [uncore_all] type=uncore max_freq_khz=90%
Using this options TuneD will limit maximum frequency of all uncore units on the Intel system to 90% of the allowable range. Except uncore10 which maximum frequency limit will be set to 4 GHz.
usb
Sets autosuspend timeout of USB devices to the value specified by the
autosuspend
option in seconds. If the devices
option is specified, the autosuspend
option applies to only
the USB devices specified, otherwise it applies to all USB devices.
The value 0
means that autosuspend is disabled.
1-1
and 1-2
[usb] devices=1-1,1-2 autosuspend=0
video
Sets various power saving features on video cards.
Radeon cards are supported.
The powersave level can be specified
by using the radeon_powersave
option. Supported values are:
-
default
-
auto
-
low
-
mid
-
high
-
dynpm
-
dpm-battery
-
dpm-balanced
-
dpm-perfomance
For additional detail, see KMS Power Management Options.
Note
|
This plug-in is experimental and the option might change in future releases. |
[video] radeon_powersave=high
Mobile hardware with amdgpu driven eDP panels can be configured
with the panel_power_savings
option.
This accepts a value range from 0 to 4, where 4 is the highest power savings
but will trade off color accuracy.
vm
Tunes selected sysctl options in /proc/sys/vm
, currently
dirty_ratio
, dirty_background_ratio
,
dirty_bytes
, and dirty_background_bytes
.
See https://docs.kernel.org/admin-guide/sysctl/vm.html for detailed
documentation of these options.
Additionaly enables or disables transparent huge pages depending on
the value of the transparent_hugepages
option. The option
can have one of three possible values: always
, madvise
and never
.
[vm] transparent_hugepages=never
The transparent_hugepage.defrag
option specifies the
defragmentation policy. Possible values for this option are always
,
defer
, defer+madvise
, madvise
and never
. For a detailed
explanation of these values refer to
Transparent Hugepage Support.
Variables in TuneD profiles
Variables expand at run time when a TuneD profile is activated.
Using TuneD variables reduces the amount of necessary typing in TuneD profiles.
There are no predefined variables in TuneD profiles. You can define your own variables by creating the [variables]
section in a profile and using the following syntax:
[variables] variable_name=value
To expand the value of a variable in a profile, use the following syntax:
${variable_name}
In the following example, the ${isolated_cores}
variable expands to 1,2
; hence the kernel boots with the isolcpus=1,2
option:
[variables] isolated_cores=1,2 [bootloader] cmdline=isolcpus=${isolated_cores}
The variables can be specified in a separate file. For example, you can add the following lines to tuned.conf
:
[variables] include=/etc/tuned/my-variables.conf [bootloader] cmdline=isolcpus=${isolated_cores}
If you add the isolated_cores=1,2
option to the /etc/tuned/my-variables.conf
file, the kernel boots with the isolcpus=1,2
option.
-
tuned.conf(5)
man page
Built-in functions in TuneD profiles
Built-in functions expand at run time when a TuneD profile is activated.
You can:
-
Use various built-in functions together with TuneD variables
-
Create custom functions in Python and add them to TuneD in the form of plug-ins
To call a function, use the following syntax:
${f:function_name:argument_1:argument_2}
To expand the directory path where the profile and the tuned.conf
file are located, use the PROFILE_DIR
function, which requires special syntax:
${i:PROFILE_DIR}
In the following example, the ${non_isolated_cores}
variable expands to 0,3-5
, and the cpulist_invert
built-in function is called with the 0,3-5
argument:
[variables] non_isolated_cores=0,3-5 [bootloader] cmdline=isolcpus=${f:cpulist_invert:${non_isolated_cores}}
The cpulist_invert
function inverts the list of CPUs. For a 6-CPU machine, the inversion is 1,2
, and the kernel boots with the isolcpus=1,2
command-line option.
-
tuned.conf(5)
man page
Built-in functions available in TuneD profiles
The following built-in functions are available in all TuneD profiles:
PROFILE_DIR
-
Returns the directory path where the profile and the
tuned.conf
file are located. exec
-
Executes a process and returns its output.
assertion
-
Compares two arguments. If they do not match, the function logs text from the first argument and aborts profile loading.
assertion_non_equal
-
Compares two arguments. If they match, the function logs text from the first argument and aborts profile loading.
kb2s
-
Converts kilobytes to disk sectors.
s2kb
-
Converts disk sectors to kilobytes.
strip
-
Creates a string from all passed arguments and deletes both leading and trailing white space.
virt_check
-
Checks whether TuneD is running inside a virtual machine (VM) or on bare metal:
-
Inside a VM, the function returns the first argument.
-
On bare metal, the function returns the second argument, even in case of an error.
-
cpulist_invert
-
Inverts a list of CPUs to make its complement. For example, on a system with 4 CPUs, numbered from 0 to 3, the inversion of the list
0,2,3
is1
. cpulist2hex
-
Converts a CPU list to a hexadecimal CPU mask.
cpulist2hex_invert
-
Converts a CPU list to a hexadecimal CPU mask and inverts it.
hex2cpulist
-
Converts a hexadecimal CPU mask to a CPU list.
cpulist_online
-
Checks whether the CPUs from the list are online. Returns the list containing only online CPUs.
cpulist_present
-
Checks whether the CPUs from the list are present. Returns the list containing only present CPUs.
cpulist_unpack
-
Unpacks a CPU list in the form of
1-3,4
to1,2,3,4
. cpulist_pack
-
Packs a CPU list in the form of
1,2,3,5
to1-3,5
. intel_recommended_pstate
-
Returns recommended intel_pstate CPUFreq driver mode based on processor generation.
Creating new TuneD profiles
This procedure creates a new TuneD profile with custom performance rules.
-
The
tuned
service is running. See Installing and Enabling Tuned for details.
-
In the
/etc/tuned/profiles/
directory, create a new directory named the same as the profile that you want to create:# mkdir /etc/tuned/profiles/my-profile
-
In the new directory, create a file named
tuned.conf
. Add a[main]
section and plug-in definitions in it, according to your requirements.For example, see the configuration of the
balanced
profile:[main] summary=General non-specialized TuneD profile [cpu] governor=conservative energy_perf_bias=normal [audio] timeout=10 [video] radeon_powersave=dpm-balanced, auto [scsi_host] alpm=medium_power
-
To activate the profile, use:
# tuned-adm profile my-profile
-
Verify that the TuneD profile is active and the system settings are applied:
$ tuned-adm active Current active profile: my-profile
$ tuned-adm verify Verification succeeded, current system settings match the preset profile. See TuneD log file ('/var/log/tuned/tuned.log') for details.
-
tuned.conf(5)
man page
Modifying existing TuneD profiles
This procedure creates a modified child profile based on an existing TuneD profile.
-
The
tuned
service is running. See Installing and Enabling Tuned for details.
-
In the
/etc/tuned/profiles/
directory, create a new directory named the same as the profile that you want to create:# mkdir /etc/tuned/profiles/modified-profile
-
In the new directory, create a file named
tuned.conf
, and set the[main]
section as follows:[main] include=parent-profile
Replace parent-profile with the name of the profile you are modifying.
-
Include your profile modifications.
Example 63. Lowering swappiness in the throughput-performance profileTo use the settings from the
throughput-performance
profile and change the value ofvm.swappiness
to 5, instead of the default 10, use:[main] include=throughput-performance [sysctl] vm.swappiness=5
-
To activate the profile, use:
# tuned-adm profile modified-profile
-
Verify that the TuneD profile is active and the system settings are applied:
$ tuned-adm active Current active profile: my-profile
$ tuned-adm verify Verification succeeded, current system settings match the preset profile. See TuneD log file ('/var/log/tuned/tuned.log') for details.
-
tuned.conf(5)
man page
Setting the disk scheduler using TuneD
This procedure creates and enables a TuneD profile that sets a given disk scheduler for selected block devices. The setting persists across system reboots.
In the following commands and configuration, replace:
-
device with the name of the block device, for example
sdf
-
selected-scheduler with the disk scheduler that you want to set for the device, for example
bfq
-
The
tuned
service is installed and enabled. For details, see https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/monitoring_and_managing_system_status_and_performance/getting-started-with-tuned_monitoring-and-managing-system-status-and-performance#installing-and-enabling-tuned_getting-started-with-tuned.
-
Optional: Select an existing TuneD profile on which your profile will be based. For a list of available profiles, see https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/monitoring_and_managing_system_status_and_performance/getting-started-with-tuned_monitoring-and-managing-system-status-and-performance#tuned-profiles-distributed-with-rhel_getting-started-with-tuned.
To see which profile is currently active, use:
$ tuned-adm active
-
Create a new directory to hold your TuneD profile:
# mkdir /etc/tuned/profiles/my-profile
-
Find the system unique identifier of the selected block device:
$ udevadm info --query=property --name=/dev/device | grep -E '(WWN|SERIAL)' ID_WWN=0x5002538d00000000_ ID_SERIAL=Generic-_SD_MMC_20120501030900000-0:0 ID_SERIAL_SHORT=20120501030900000
NoteThe command in the this example will return all values identified as a World Wide Name (WWN) or serial number associated with the specified block device. Although it is preferred to use a WWN, the WWN is not always available for a given device and any values returned by the example command are acceptable to use as the device system unique ID.
-
Create the
/etc/tuned/profiles/my-profile/tuned.conf
configuration file. In the file, set the following options:-
Optional: Include an existing profile:
[main] include=existing-profile
-
Set the selected disk scheduler for the device that matches the WWN identifier:
[disk] devices_udev_regex=IDNAME=device system unique id elevator=selected-scheduler
Here:
-
Replace IDNAME with the name of the identifier being used (for example,
ID_WWN
). -
Replace device system unique id with the value of the chosen identifier (for example,
0x5002538d00000000
).To match multiple devices in the
devices_udev_regex
option, enclose the identifiers in parentheses and separate them with vertical bars:devices_udev_regex=(ID_WWN=0x5002538d00000000)|(ID_WWN=0x1234567800000000)
-
-
-
Enable your profile:
# tuned-adm profile my-profile
-
Verify that the TuneD profile is active and applied:
$ tuned-adm active Current active profile: my-profile
$ tuned-adm verify Verification succeeded, current system settings match the preset profile. See TuneD log file ('/var/log/tuned/tuned.log') for details.
Related information
-
The
tuned.conf(5)
man page -
The TuneD project website: https://tuned-project.org/