# TuneD documentation: Optimizing system throughput, latency, and power consumption

version 2.24.1, 2024-10-09

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.

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.

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

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.

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

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

### 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 3. 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:

       # yum install tuned

2. Enable and start the `tuned` service:

       # systemctl enable --now tuned

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

       # yum 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

- The `tuned` service is running. See Installing and Enabling Tuned for details.

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

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

Prerequisites

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

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.

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

Example 5. 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.

### 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 6. 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.

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

### 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 8. 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 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 9. 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 10. 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

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

Example 11. Selecting a platform profile

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

Example 12. Set the timeout value to 10s and enforce the controller reset

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

Example 13. Modifying the kernel command line

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

Example 14. Modifying the kernel command line, example with inheritance

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.

Example 15. Adding an overlay initrd image

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

Example 16. Do not change grub configuration

    [bootloader]
    skip_grub_config=True
    cmdline=+systemd.cpu_affinity=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.

Example 17. Operate only on the `sda` block device

    [disk]
    devices=sda

The `elevator` option sets the Linux I/O scheduler.

Example 18. Use the bfq I/O scheduler on the `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.

Example 19. Use a medium-agressive power management with spindown

    [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`).

Example 20. Set the `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.

Example 21. Moving all IRQs to CPU0, except irq16, which is directed to CPU2

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

Example 22. Skip CPUs 2,4 and 9-13 when rebalancing IRQs

    [irqbalance]
    banned_cpus=2,4,9-13

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

Example 23. Load module `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.

Example 24. (Re)load module `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 the `ethtool` utility.

  Example 25. 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 26. 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, use `ethtool -k device`. The syntax of the option is the same as the `coalesce` option.

  Example 27. 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, use `ethtool -a device`. The syntax of the option is the same as the `coalesce` option.

  Example 28. 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, use `ethtool -g device`. The syntax of the option is the same as the `coalesce` option.

  Example 29. 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, use `ethtool -l device`. The syntax of the option is the same as the `coalesce` option.

  Example 30. 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 31. 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 uses `ip` 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 use `ip link show` and the current value is shown after the qlen column.

  Example 32. Adjust the length of the transmit queue

      [net]
      txqueuelen=5000

`mtu`

  The `mtu` option allows changing MTU (Maximum Transmission Unit). It uses `ip` 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 use `ip link show` and the current value is shown after the MTU column.

  Example 33. 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.

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

Example 34. Running a Bash script from a profile

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 four values: `min_power`, `med_power_with_dipm`, `medium_power` and `max_performance`.

Note | ALPM is only available on SATA controllers that use the Advanced Host Controller Interface (AHCI).

Example 35. ALPM setting when extended periods of idle time are expected

    [scsi_host]
    alpm=med_power_with_dipm

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

Example 36. Increase the AVC cache threshold for hosts with containers.

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

Example 37. Start and enable the `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.

Example 38. Adjusting the kernel runtime kernel.sched_min_granularity_ns value

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

Example 39. Ignore corrected errors and associated scans that cause latency spikes

    [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 (`-`).

Example 40. Set the CPUAffinity for `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.

Example 41. Limiting maximum uncore frequency

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

Example 42. Turn off USB autosuspend for USB devices `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.

Example 43. Setting powersave level for the Radeon video card to high

    [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`.

Example 44. Disable transparent hugepages

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

Example 45. 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 46. 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:

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

`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` to `1,2,3,4`.

`cpulist_pack`

  Packs a CPU list in the form of `1,2,3,5` to `1-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.

Prerequisites

- The `tuned` service is running. See Installing and Enabling Tuned for details.

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

- The `tuned` service is running. See Installing and Enabling Tuned for details.

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

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

Procedure

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

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

- https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/monitoring_and_managing_system_status_and_performance/customizing-tuned-profiles_monitoring-and-managing-system-status-and-performance.

### Related information

- The `tuned.conf(5)` man page

- The TuneD project website: https://tuned-project.org/