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

Additional resources

  • 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

throughput-performance

The best throughput performance

Virtual machines

virtual-guest

The best performance. If you are not interested in the best performance, you can change it to the balanced or powersave profile.

Other cases

balanced

Balanced performance and power consumption
Additional resources

  • 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. The radeon_powersave option uses the dpm-balanced value if it is supported, otherwise it is set to auto.

It changes the energy_performance_preference attribute to the normal energy setting. It also changes the scaling_governor policy attribute to either the conservative or powersave 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 the powersave or power energy setting. It also changes the scaling_governor policy attribute to either the ondemand or powersave CPU governor.

Note

In certain cases, the balanced profile is more efficient compared to the powersave 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 to performance.

It changes the energy_performance_preference and scaling_governor attribute to the performance profile.

accelerator-performance

The accelerator-performance profile contains the same tuning as the throughput-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 to performance and the CPU is locked to the low C states (by PM QoS).

It changes the energy_performance_preference and scaling_governor attribute to the performance 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-related sysctl parameters.

It inherits the latency-performance profile which changes the energy_performance_preference and scaling_governor attribute to the performance 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 or throughput-performance profile, and changes the energy_performance_preference and scaling_governor attribute to the performance 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 the energy_performance_preference and scaling_governor attribute to the performance 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 the energy_performance_preference and scaling_governor attribute to the performance 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 the tuned-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 the tuned-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 the tuned-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.

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 take precedence.

Example 1. Low power consumption in a virtual guest

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.
Additional resources

  • 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 and sysfs settings and one-shot activation of several configuration tools such as ethtool.

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 the dynamic_tuning option to 1. 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 the update_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.

Example 2. Static and dynamic tuning on a workstation

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.

Procedure

  1. Install the tuned package:

    # dnf install tuned

  2. Enable and start the tuned service:

    # systemctl enable --now tuned

  3. Optionally, install TuneD profiles for real-time systems:

    # dnf install tuned-profiles-realtime tuned-profiles-nfv

  4. 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.

Procedure

  • 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
Additional resources

  • The tuned-adm(8) man page.

Setting a TuneD profile

This procedure activates a selected TuneD profile on your system.

Prerequisites
Procedure

  1. Optionally, you can let TuneD recommend the most suitable profile for your system:

    # tuned-adm recommend

balanced

  2. Activate a profile:

    # tuned-adm profile selected-profile

    Alternatively, you can activate a combination of multiple profiles:

    # tuned-adm profile profile1 profile2
    Example 3. A virtual machine optimized for low power consumption

    The 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

  3. View the current active TuneD profile on your system:

    # tuned-adm active

Current active profile: selected-profile

  4. Reboot the system:

    # reboot
Verification steps

  • 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.
Additional resources

  • 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.

Procedure

  • 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
Additional resources

  • tuned-adm(8) man page

Customizing TuneD profiles

You can create or modify TuneD profiles to optimize system performance for your intended use case.

Prerequisites

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 called tuned.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.

Example 4. User-defined profile directories

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.

Additional resources

  • tuned.conf(5) man page.

Syntax of profile configuration

The tuned.conf file uses INI syntax. It 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.

Additional resources

  • 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.

Example 5. A power-saving profile based on balanced

The following is an example of a custom profile that extends the balanced profile and disables the capability of the CPU to boost above nominal frequencies for brief periods.

[main]
include=balanced

[cpu]
boost=0
Additional resources

  • tuned.conf(5) man page

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 no devices 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 the devices=* option.

Example 6. Matching block devices with a plug-in

The following example matches all block devices starting with sd, such as sda or sdb, 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 and sda2:

[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:

Example 7. Matching block devices using the short syntax
[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.

Additional resources

  • tuned.conf(5) man page

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}
Example 8. Isolating CPU cores using variables

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.

Additional resources

  • 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}
Example 9. Isolating CPU cores using variables and built-in functions

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.

Additional resources

  • tuned.conf(5) man page

Built-in functions available in TuneD profiles

The following built-in functions are available in all TuneD profiles:

cpulist_present

Checks whether the CPUs from a given CPU list are present on the system. Returns a CPU list containing only the present CPUs from the given list.

cpulist_pack

Packs a CPU list into the most succint form.

The following returns 1-3,5:

${f:cpulist_pack:1,2,3,5}

s2kb

Converts disk sectors to kilobytes.

cpulist_invert

Inverts a CPU list, i.e., returns its complement. The complement is computed from the list of online CPUs in /sys/devices/system/cpu/online.

On a system with 4 CPUs numbered from 0 to 3, the following will return 1.

${f:cpulist_invert:0,2,3}

cpulist2hex_invert

Converts a CPU list into a hexadecimal CPU mask and inverts it.

On a system with 4 CPUs numbered from 0 to 3, the following will return 00000002, because only CPU1 is in the complement.

${f:cpulist2hex_invert:0,2,3}

cpulist_unpack

Unpacks a CPU list into a form with no ranges.

The following returns 1,2,3,5:

${f:cpulist_unpack:1-3,5}

assertion_non_equal

Compares the second argument and the third argument. If they match, the function logs the text from the first argument as an error and aborts profile loading.

The following will pass without errors:

${f:assertion_non_equal:fatal error:3:5}

check_net_queue_count

Checks whether the first argument is a valid queue count for net devices. If yes, returns it, otherwise returns the number of housekeeping CPUs.

log

Returns the concatenation of its arguments and also logs the return value, which is useful for debugging.

Example 10. Using log to debug intermediate values

Since the arguments of log "fall through" the function, it can be used as below for debugging intermediate values:

[variables]
isolated_cores_hex = ${f:cpulist2hex:${f:log:${f:calc_isolated_cores}}}

cpuinfo_check

Checks regexes against the content of /proc/cpuinfo.

Accepts arguments in the form REGEX1, STR1, REGEX2, STR2, …​[, STR_FALLBACK].

If REGEX1 has a match in /proc/cpuinfo, it returns STR1.

If REGEX2 has a match, it returns STR2.

The function stops on the first match, i.e., if REGEX1 has a match, no more regexes are processed. If no regex has a match, STR_FALLBACK is returned. If there is no fallback value, it returns an empty string.

strip

Creates a string by concatenating all arguments, stripping any leading or trailing whitespace from the result.

The following returns foo bar:

${f:strip:  foo :bar  }

cpulist2devs

Converts a CPU list into a comma-separated list of device names.

The following will return cpu1,cpu2,cpu3,cpu5:

${f:cpulist2devs:1-3,5}

hex2cpulist

Converts a hexadecimal CPU mask into a CPU list.

The following will return 0,1,2,3:

${f:hex2cpulist:00000007}

package2uncores

Returns a comma-separated list of uncore devices for a package (socket). Multiple socket numbers can be specified in separate arguments.

On a system with a single socket and a single die, the following will return package_00_die_00:

${f:package2uncores:0}

intel_recommended_pstate

Returns the recommended intel_pstate CPUFreq driver mode based on the CPU generation.

Note
 Intel recommends to use the P-State driver in active mode with HWP enabled starting from the Ice Lake CPU generations. In older CPU generations, setting P-State to active can introduce jitters which were historically seen around and tested with RHEL-7.4. Beginning with the Ice Lake generation, Intel has fixed these issues.

kb2s

Converts kilobytes to disk sectors.

calc_isolated_cores

Calculates and returns a list of isolated cores. The argument specifies how many cores per socket should be reserved for housekeeping. If not specified, a single core is reserved per socket and the rest is isolated.

Reserve two cores per socket for housekeeping and return the list of remaining cores:

${f:calc_isolated_cores:2}

exec

Executes a process and returns its output.

The following executes cat /etc/tuned/active_profile:

${f:exec:cat:/etc/tuned/active_profile}

cpulist2hex

Converts a CPU list into a hexadecimal CPU mask.

The following will return 00000007.

${f:cpulist2hex:0-3}

cpulist_online

Returns a CPU list containing the online CPUs from the given CPU list.

On a system with 8 CPUs where the first 4 CPUs (0 to 3) are offline, the following returns 4-6:

${f:cpulist_online:0-6}

assertion

Compares the second argument and the third argument. If they do not match, the function logs the text from the first argument as an error and aborts profile loading.

The following will log the error message fatal error and abort profile loading:

${f:assertion:fatal error:3:5}

lscpu_check

Checks regexes against the output of lscpu.

Accepts arguments in the form REGEX1, STR1, REGEX2, STR2, …​[, STR_FALLBACK].

If REGEX1 has a match in the output of lscpu, it returns STR1.

If REGEX2 has a match, it returns STR2.

The function stops on the first match, i.e., if REGEX1 has a match, no more regexes are processed. If no regex has a match, STR_FALLBACK is returned. If there is no fallback value, returns an empty string.

package2cpus

Returns a comma-separated list of CPU devices for a package (socket). Multiple socket numbers can be specified in separate arguments.

On a system with two CPU sockets, both with 4 cores, the following will return cpu0,cpu1,cpu2,cpu3,cpu4,cpu5,cpu6,cpu7:

${f:package2cpus:0:1}

virt_check

Checks whether TuneD is running inside a virtual machine (VM) or on bare metal.

Inside a VM, it returns the first argument. Otherwise returns the second argument (even on error).

The following returns VM when running in a virtual machine:

${f:virt_check:VM:Bare}

regex_search_ternary

Ternary regex operator.

It takes arguments in the following form: STR1, REGEX, STR2, STR3

If REGEX is matched within STR1, returns STR2, otherwise returns STR3.

Creating new TuneD profiles

This procedure creates a new TuneD profile with custom performance rules.

Prerequisites
Procedure

  1. 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

  2. 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=med_power_with_dipm

  3. To activate the profile, use:

    # tuned-adm profile my-profile

  4. 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.
Additional resources

  • tuned.conf(5) man page

Modifying existing TuneD profiles

This procedure creates a modified child profile based on an existing TuneD profile.

Prerequisites
Procedure

  1. 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

  2. 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.

  3. Include your profile modifications.

    Example 11. Lowering swappiness in the throughput-performance profile

    To use the settings from the throughput-performance profile and change the value of vm.swappiness to 5, instead of the default 10, use:

    [main]
include=throughput-performance

[sysctl]
vm.swappiness=5

  4. To activate the profile, use:

    # tuned-adm profile modified-profile

  5. 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.
Additional resources

  • 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

Prerequisites
Procedure

  1. Optional: Select an existing TuneD profile on which your profile will be based. For a list of available profiles, see Tuned profiles distributed with RHEL.

    To see which profile is currently active, use:

    $ tuned-adm active

  2. Create a new directory to hold your TuneD profile:

    # mkdir /etc/tuned/profiles/my-profile

  3. 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
    Note

    The 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.

  4. Create the /etc/tuned/profiles/my-profile/tuned.conf configuration file. In the file, set the following options:

    1. Optional: Include an existing profile:

      [main]
include=existing-profile

    2. 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)

  5. Enable your profile:

    # tuned-adm profile my-profile
Verification steps

  1. 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.
Additional resources