System Analysis and Tuning Guide

13.1 Introduction to TuneD #

The TuneD application monitors and adjusts system settings on certain SUSE Linux Enterprise Server workloads based on usage of different system resources, such as the CPU and the disk. The primary goal of TuneD is to deliver energy efficiency, optimized performance and efficient resource utilization without requiring manual configuration of low-level system settings, which can be complex and error-prone.

System administrators can apply predefined or customized TuneD profiles based on the current usage scenario or workload on the system. These profiles contain settings for certain system components such as the CPU, disk I/O schedulers, virtual memory, and power management. The system components are managed by plug-ins, which tune the system based on the activated profile settings.

13.2 Components of TuneD #

The TuneD application consists of the following key components:

tuned daemon

The core daemon process that runs in the background, monitoring system usage and applying tuning settings. It handles profile switching and coordination of the other components. The following items are associated with the daemon:

The tuned command that you can use after enabling TuneD using systemctl. By default, when invoked from the terminal manually, tuned runs as a normal process. However, you can use the --daemon option to run it as a background process.
A tuned systemd service that manages the daemon process, such as starting the daemon at boot time, stopping or restarting it, and ensuring it runs with the necessary permissions and environment.

For more information, read the man page for tuned.

> man tuned

tuned-adm

A command-line utility to manage or administer the tuned daemon. To understand the basics of managing the tuned daemon using tuned-adm, see Section 13.4.2.1, “Using tuned-adm”.

Profiles

A TuneD profile is a collection of settings for system components that you can apply to tune the system. System administrators can either use the supported profiles that are installed at /usr/lib/tuned/ as part of the tuned package, or apply customized profiles by creating them at /etc/tuned/. If the filenames for a custom and a supported profile matches, the custom profile takes precedence when applied. For more information, see Section 13.4, “TuneD profiles”.

Plug-ins

A TuneD plug-in is an implementation of tuning logic for different subsystems. A plug-in is invoked when a profile contains a setting that is relevant to the subsystem it controls. The plug-in tunes the subsystem based on the value of the relevant setting. A few key and most frequently used plug-ins manage subsystems, such as the CPU, disk, network, virtual machines, video and audio. In addition, there are optional monitoring plug-ins that monitor certain subsystems and pass on relevant information to the daemon for dynamic tuning. For more information, see Section 13.6, “TuneD plug-ins”.

Extension scripts

System administrators can extend the ecosystem of TuneD profiles and plug-ins using custom scripts that can be executed before or after a profile is applied. To use an extension script, specify the path and the type of the script in the profile configuration. Such extensibility allows the implementation of custom tuning logic and offers more control over the entire process of applying profiles. For more information, see Section 13.4.2.2, “Using profile hooks”.

13.3 Managing TuneD #

This section covers the essential tasks for managing the tuned service lifecycle on SUSE Linux Enterprise Server. It guides you through installing the tuned package from official repositories, enabling and disabling the associated systemd service for automatic startup, and running the tuned daemon either as a background process managed by systemd or as a normal foreground process. Proper management of the tuned service ensures that the dynamic tuning capabilities are available when required and can be controlled effectively, allowing you to optimize system performance and resource utilization based on your needs.

13.3.1 Installing TuneD #

The recommended way to install a supported version of TuneD is to install the tuned package using the zypper package manager.

Note: tuned is available only for SUSE Linux Enterprise Server

The tuned package is available only in the official SUSE Linux Enterprise Server repositories. There is no equivalent package available in the official SUSE Linux Enterprise Desktop repositories.

To install the tuned daemon, command-line utilities, profiles and plug-ins, run the following command:
```
> sudo zypper install -y tuned
```
Verify the installation by running the following commands:
```
> tuned --help
```
```
> tuned-adm --help
```
(Optional) To know more, read the man pages for tuned, tuned-adm, tuned-profiles and tuned.conf.

13.3.2 Enabling `tuned` #

To enable tuned, perform the following procedure:

Check the status of the tuned service:
```
> sudo systemctl status tuned
```
By default, the status of the service is disabled.
To enable a systemd service for future boots so that the tuned daemon starts automatically at the boot time, run the following command:
```
> sudo systemctl enable tuned
```
However, this command does not start the tuned process. If you check the status of the systemd service now, it should be enabled and inactive.

13.3.3 Starting `tuned` #

After enabling the associated systemd service for tuned, for the current session you can start tuned either as a background daemon or as a normal process connected to the TTY.

Alternatively, you can enable the associated systemd service and start the daemon simultaneously.

Depending on how you want to start tuned across sessions, you have the following options:
- To start tuned only for the current session, perform one of the following steps:
  1. Start tuned as a background process and let systemd manage the states of the daemon:
```
> sudo systemctl start tuned
```
    Note: Profile run by tuned
    Once activated, tuned starts tuning the system based on the default profile that is appropriate for the system, or the currently active profile. To change it, use the tuned-adm command. For more information, see Section 13.4, “TuneD profiles” and Section 13.6, “TuneD plug-ins”.
  2. Start tuned as a normal process connected to the TTY only for the current session:
```
> sudo tuned
```
    Tip: Running the tuned command
    You can use this command to activate a profile, or even run it as a daemon. For more information, run the tuned --help command.
- To enable a systemd service for future boots and simultaneously start the tuned daemon in the current session, run the following command:
```
> sudo systemctl enable --now tuned
```

13.3.4 Disabling `tuned` #

As a best practice, perform the following steps to disable tuned:

Check the status of the tuned systemd service:
```
> sudo systemctl status tuned
```
Turn off or disable all tuning settings applied earlier:
```
> sudo tuned-adm off
```
If the status of the tuned daemon is active, stop the daemon:
```
> sudo systemctl stop tuned
```
To stop the tuned daemon from being automatically activated during the next boot, you have two options:
- Disable only the associated systemd service:
```
> sudo systemctl disable tuned
```
- Simultaneously disable the tuned systemd service and stop the tuned daemon immediately:
```
> sudo systemctl disable --now tuned
```

13.4 TuneD profiles #

TuneD optimizes SUSE Linux Enterprise Server systems using predefined profiles with settings tailored for different use cases. These profiles adjust several system settings, including CPU governor policies, disk I/O scheduling, network parameters, and kernel parameters, to enhance performance, energy efficiency, or other system characteristics. Each profile is designed for specific scenarios, such as high throughput, low latency, power saving, or virtualized environments. System administrators can switch between profiles using the tuned-adm command and customize or combine profiles to meet unique requirements. This section covers the basics of managing, creating and customizing TuneD profiles.

13.4.1 Supported TuneD profiles #

SUSE Linux Enterprise Server supports the following profiles:

balanced: The balanced profile provides a general-purpose optimization of the system, offering a good compromise between performance and energy consumption. It dynamically adjusts CPU frequency and power states, and balances I/O and network performance with power saving, making it suitable for most desktop and server environments.
cpu-partitioning: The cpu-partitioning profile is designed for systems where CPU resources need to be partitioned for specific tasks or applications. It configures CPU isolation and affinity settings and adjusts scheduler parameters to ensure predictable performance and reduce interference between processes. The configuration variables for this profile are defined in /etc/tuned/cpu-partitioning-variables.conf.
desktop: The desktop profile optimizes the system for desktop environments, enhancing performance for graphical interfaces and desktop applications. It optimizes CPU and I/O performance, settings for low-latency audio and video playback, and reduces power-saving measures to ensure a smooth and responsive user experience.
latency-performance: The latency-performance profile prioritizes low latency and deterministic performance over power savings. It sets the CPU governor to performance mode, adjusts kernel parameters to reduce latency, and disables power-saving features that could introduce delays, making it suitable for real-time applications and high-performance computing.
mssql: The mssql profile optimizes the system for running Microsoft SQL Server by tuning CPU and memory settings, optimizing disk I/O for database access patterns, and enhancing network settings for improved database connectivity.
network-latency: The network-latency profile optimizes the network performance for applications requiring low latency, such as financial trading platforms and real-time communication systems. It configures network settings to reduce latency, sets the CPU governor to performance mode, and adjusts kernel parameters to prioritize network traffic.
network-throughput: The network-throughput profile enhances the system for sustained high data transfer rates, particularly on older CPUs or high-speed networks. It tunes network stack parameters for maximum throughput and optimizes CPU settings to handle high network loads.
powersave: Optimizes the system for energy efficiency, possibly at the cost of performance. While using this configuration as a stand-alone or merged profile, carefully analyze the deployment use case and ensure that it saves more power than the balanced profile.
throughput-performance: The throughput-performance profile maximizes overall system performance for general-purpose servers handling diverse tasks. It sets the CPU governor to performance mode, tunes I/O and network settings for high throughput, and adjusts kernel parameters to enhance system performance.
virtual-guest: The virtual-guest profile optimizes performance and efficiency for virtual machines running as guests. It tunes CPU and memory settings for virtualized environments and adjusts disk and network settings to ensure optimal resource utilization and VM performance.
virtual-host: The virtual-host profile enhances systems running KVM guests by optimizing resource allocation and performance. It configures CPU and memory settings for hosting multiple virtual machines, tunes I/O and network settings, and enhances kernel parameters to support virtualization.

For information on the TuneD profile configuration files, see the following sections:

13.4.2 Managing TuneD profiles #

If you just want to activate a profile, pass the profile name to the tuned command:

> sudo tuned --profile PROFILE_NAME

However, the best practice for managing the lifecycle of TuneD profiles is to use the tuned-adm command-line tool.

13.4.2.1 Using `tuned-adm` #

You can use the tuned-adm command to perform the following tasks:

List all available profiles.
```
> sudo tuned-adm list
```
List active profile.
```
> sudo tuned-adm active
```
Display information about the current profile.
```
> sudo tuned-adm profile_info
```
Display information about a specified profile.
```
> sudo tuned-adm profile_info PROFILE_NAME
```
Recommend a profile based on the current system usage.
```
> sudo tuned-adm recommend
```
By default, TuneD in SUSE Linux Enterprise Server recommends a profile based on the configuration mentioned in /usr/lib/tuned/recommend.d/50-tuned.conf. You can also define custom recommendation rules by creating the file /etc/tuned/recommend.conf, which takes precedence over the default rules.
Display the current profile selection mode.
```
> sudo tuned-adm profile_mode
```
Select a profile automatically, and switch to the recommended profile.
```
> sudo tuned-adm auto_profile
```
Manually switch to a specified profile.
```
> sudo tuned-adm profile PROFILE_NAME
```
Verify that a profile has been successfully applied, and the system state matches the profile's configurations.
```
> sudo tuned-adm verify
```
Turn off all tunings.
```
> sudo tuned-adm off
```

For more information on tuned-adm, see its help information or man page.

> sudo tuned-adm --help

> man tuned-adm

13.4.2.2 Using profile hooks #

Profile hooks are specific scripts that are executed at different stages of a profile's lifecycle. They allow for more granular control and customization of what happens when a profile is applied. Profile hooks are generally placed in the profile directory under /etc/tuned/PROFILE_NAME/ for custom profiles, and /usr/lib/tuned/PROFILE_NAME/ for the default or supported profiles.

Profile hooks can be used to execute custom commands or scripts before or after certain events, such as:

Starting a profile
Stopping a profile
Verifying a profile
Fully rolling back a profile

Example 13.1: Creating and applying a profile hook #

For example, in a custom profile that mixes the balanced and powersave profiles, we can include a profile hook that displays certain relevant information before applying the profile.

Create a script named start.sh in the custom profile directory /etc/tuned/CUSTOM_PROFILE_NAME/ with the following content:

Example 13.2: Custom hook script to handle specific tasks before applying the custom profile #

#!/bin/bash

# Example task: Log the current CPU governor and energy performance bias
echo "Current CPU governor: $(cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor)" >>
/var/log/tuned/CUSTOM_PROFILE_NAME.log
echo "Current energy performance bias: $(cat /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_bias)" >> /var/log/tuned/CUSTOM_PROFILE_NAME.log

# Example task: Check for specific conditions before applying settings
if [ ! -d "/sys/devices/system/cpu/cpufreq/policy0" ]; then
    echo "CPU frequency scaling not available, aborting profile application." >> /var/log/tuned/CUSTOM_PROFILE_NAME.log
    exit 1
fi

# Example task: Notify about the upcoming profile application
echo "Preparing to apply custom profile settings." >> /var/log/tuned/CUSTOM_PROFILE_NAME.log

Ensure the script is executable:

> sudo chmod +x /etc/tuned/CUSTOM_PROFILE_NAME/start.sh

Include the path to the custom script in /etc/tuned/CUSTOM_PROFILE_NAME/tuned.conf by using the [script] section:

Example 13.3: TuneD profile with custom script path #

[main]
include=balanced

[cpu]
governor=powersave
energy_perf_bias=powersave

[disk]
# Inherit settings from balanced profile

[sysctl]
vm.swappiness=10

[script]
script=/etc/tuned/CUSTOM_PROFILE_NAME/start.sh

Apply the custom profile to test the custom script:
```
> sudo tuned-adm profile CUSTOM_PROFILE_NAME
```

13.5 TuneD configuration #

Configuration files form the foundation of TuneD and its profiles. In SUSE Linux Enterprise Server, the /etc/tuned/ file is the main configuration file for the tuned daemon. This file contains global settings that affect the overall behavior of TuneD.

Also, each TuneD profile has its tuned.conf configuration file that defines the specific tuning parameters and plug-in settings for a particular profile. The profile-specific configuration files are divided into sections, each corresponding to a specific TuneD plug-in or a group of related settings. System administrators can specify system tuning parameters across different subsystems, such as CPU, disk and network. For more information on TuneD plug-ins, see Section 13.6, “TuneD plug-ins”.

13.5.1 Global TuneD configuration #

When tuned starts running (as a daemon, by default), the settings in the /etc/tuned/tuned-main.conf global configuration file are applied on the system. This action prepares the system to apply additional profile-specific tuning in the subsequent stages.

The default /etc/tuned/tuned-main.conf file contains the following global settings:

Example 13.4: Default global TuneD configuration #

daemon = 1 1

dynamic_tuning = 1 2

sleep_interval = 1 3

update_interval = 10 4

recommend_command = 1 5

reapply_sysctl = 1 6

default_instance_priority = 0 7

udev_buffer_size = 1MB 8

log_file_count = 2 9

log_file_max_size = 1MB 10

1	Specifies whether to use the `tuned` daemon. When set to `1`, the daemon is used, enabling features such as D-Bus integration, settings rollback, hotplug support, and dynamic tuning. Disabling the daemon by setting it to `0` is not recommended, as it limits TuneD's functionality to static tuning only.
2	Enables or disables dynamic tuning of devices. When set to `1`, TuneD dynamically adjusts settings based on system activity. When disabled by setting it to `0`, only static tuning is applied. Since dynamic tuning relies on the daemon to function, setting `dynamic_tuning=1` becomes irrelevant when the daemon is disabled by setting it to `daemon=0`.
3	Defines the interval in seconds that the `tuned` daemon sleeps before checking for events. A higher value reduces overhead but increases response time to changes.
4	Sets the interval in seconds for updating dynamic tunings. This value must be a multiple of `sleep_interval`.
5	Controls the availability of the `tuned-adm recommend` command. When enabled by setting it to `1`, `tuned` parses the custom recommendation figuration at `/etc/tuned/recommend.conf` or the default recommendation configuration `/usr/lib/tuned/recommend.d/50-tuned.conf` and provides profile recommendations. When disabled by setting it to `0`, the daemon returns a single hard-coded profile, typically `balanced`.
6	Determines whether system sysctl settings from files such as `/etc/sysctl.conf` and `/etc/sysctl.d` should be reapplied after TuneD sysctl settings are applied. When enabled by setting to 1, system sysctl settings override TuneD sysctl settings.
7	Specifies the default priority assigned to the TuneD instances. Higher values indicate a higher priority.
8	Defines the buffer size for udev events. This setting helps manage the amount of data processed from udev.
9	Sets the number of log files to keep in the directory `/var/log/tuned/`. This helps in log rotation, where older logs are archived and new logs are created.
10	Specifies the maximum size of each log file before it is rotated. This prevents log files from growing indefinitely. For example, when the default log file `/var/log/tuned/tuned.log` reaches the size set by this parameter, a new file is started.

Warning

Modify the values of the global settings in /etc/tuned/ only when you are sure of its effects on the behavior of TuneD.

For a detailed overview of the main TuneD configuration file, read its man page:

> man 5 tuned-main.conf

13.5.2 Supported profile configuration #

Every supported TuneD profile has its own directory under /usr/lib/tuned/, and each such profile directory contains the /usr/lib/tuned/PROFILE_NAME/tuned.conf configuration file. The configuration file contains a default set of plug-ins, parameters and options that are appropriate for the profile.

13.5.2.1 General syntax of TuneD profiles #

The general syntax for a profile configuration file is as follows:

[main]
summary=SUMMARY_TEXT_STRING
include=ANOTHER_PROFILE_NAME_AS_BASE

[PLUG-IN]
PARAMETER=OPTION
PARAMETER=OPTION
...

[PLUG-IN]
# COMMENT_STRING
PARAMETER=OPTION

...

For an overview of the TuneD configuration files, read its man page:

> man 5 tuned.conf

13.5.3 Custom profile configuration #

Also, you can define custom profiles. For each custom profile, create a PROFILE_NAME directory in /etc/tuned/, and place its configuration file within its own directory. For example, the configuration file for a custom profile can be at the path /etc/tuned/PROFILE_NAME/tuned.conf. However, if there is a match between PROFILE_NAME in the default path /usr/lib/tuned/PROFILE_NAME path and the custom path /etc/tuned/PROFILE_NAME, the custom profile configuration is prioritized and applied. As a best practice for customizing a supported profile, copy it from /usr/lib/tuned/ to /etc/tuned/ and then modify it. This preserves the original profile and separates custom configurations.

Note: Path to TuneD profile configuration files

Although not recommended, you can specify paths in the /etc/tuned/ other than the standard paths for supported and custom profiles:

profile_dirs=/etc/tuned/,/usr/lib/tuned/,/PATH/TO/CUSTOM/DIRECTORY/

The directories are searched for profiles according to the order of their listing. In the above example, /etc/tuned/ is searched first, followed by /usr/lib/tuned/ and /PATH/TO/CUSTOM/DIRECTORY/.

Warning

SUSE does not support any profile that is not part of the supported profiles supplied with the tuned from official SUSE Linux Enterprise Server repositories. Create and apply a custom profile on a production system only if you are sure of its effect.

13.5.3.1 Creating a custom profile by merging configurations #

As a best practice, always merge two or more profiles by manually creating a custom profile configuration. This approach makes you aware of the exact mix of parameters and plug-ins in your custom merged profile. It is a more involved process compared to applying two or more profiles simultaneously without checking the result of the merge that gets generated on-the-fly.

As an example, consider a simple merge of the balanced and powersave profiles.

Example 13.5: Merging balanced and powersave TuneD profiles #

Create the path for the custom profile:

> sudo mkdir /etc/tuned/CUSTOM_PROFILE_NAME

Create a profile configuration file in the following directory:
```
> sudo vi /etc/tuned/CUSTOM_PROFILE_NAME/tuned.conf
```

Add the following configuration to the file:

Example 13.6: Merged configuration for balanced and powersave TuneD profiles #

[main]
include=balanced 1

[cpu] 2
governor=powersave
energy_perf_bias=powersave

[disk] 3
# Inherit settings from balanced profile

[sysctl]
vm.swappiness=10 4

1	Include the `balanced` profile as a base, which is suitable for general purpose use.
2	Overrides CPU parameters such as `governor` and `energy-perf-bias` to `powersave`.
3	Inherit disk settings from the `balanced` profile.
4	Add a sysctl parameter to reduce swappiness, which can be beneficial for both performance and power consumption in certain scenarios.

Save the configuration file and exit the text editor.
Apply the new custom profile after merging certain parameters from balanced and powersave profiles.
```
> sudo tuned-adm profile CUSTOM_PROFILE_NAME
```

13.6 TuneD plug-ins #

TuneD plug-ins are modular components that extend the functionality of the TuneD system daemon. These plug-ins allow system administrators to create custom optimization profiles tailored to specific workloads or hardware configurations. By leveraging several system metrics and user-defined parameters, TuneD plug-ins can dynamically adjust kernel settings, CPU frequencies, disk I/O schedulers, and other low-level system parameters to achieve optimal performance and energy efficiency. While the core tuned package includes several preconfigured profiles, you can extend it through custom plug-ins for fine-grained control over the system.

The general syntax for including plug-ins in the TuneD profile configuration files is as follows:

...
[PLUGIN-NAME]
PARAMETER_1=VALUE_1
PARAMETER_2=VALUE_2
...

The supported TuneD profiles for SUSE Linux Enterprise Server have multiple plug-ins and their parameters included within them. To see a list of all such plug-ins, run the following command:

> sudo grep -r '\[.*\]' /usr/lib/tuned/*/tuned.conf | sort -u

13.6.1 Supported TuneD plug-ins #

On SUSE Linux Enterprise Server, the following TuneD plug-ins are supported:

main

main is not a plug-in, but a special section in the TuneD profile configuration files that provides overall settings and metadata for the profile. The most commonly used parameters for the [main] section are as follows:

summary: A summary of the key functionality of the profile.
include: Provision to include other profiles as a parent, so that its configuration can be inherited as a base. In case of conflict, the configuration of the child profile takes precedence over the configuration of the included profile.
Note: Impact of updated TuneD profile
When the configuration for a parent profile is updated, the child profiles that inherit the parent profile also get impacted.

modules

The modules plug-in manages kernel modules within the profiles. It can load or unload specific modules when a profile is activated, allowing administrators to optimize system behavior for different workloads by controlling which kernel modules are active. When this plug-in is used, TuneD writes information about the kernel modules in the /etc/modprobe.d/tuned.conf file.

If you need to add a kernel module parameter that should be handled by tuned, include it in the profile configuration using the following syntax:

[modules]
MODULE_NAME=MODULE_PARAMETERS1

1	You can mention multiple module parameters separated by comma.

If you want the module to be reloaded automatically, use the +r option:

[modules]
MODULE_NAME=+r,MODULE_PARAMETERS

For example:

Example 13.7: Automatic reload of kernel modules by TuneD #

[modules]
cpufreq_conservative=+r,down_threshold=20,up_threshold=80,sampling_rate=20000 1

1

cpufreq_conservative is a kernel module that adjusts the CPU clock speed based on the system load. It is more conservative in its frequency scaling compared to other governors like ondemand.
The =+r syntax indicates that the module should be loaded if it is not already, and TuneD keeps track of how many profiles are using this module. When a module with +r is loaded, TuneD increments the reference count for this module. If the profile is later deactivated, the reference count is decremented. The module is unloaded only when the reference count reaches zero, which implies that no other active profile is using it.
The parameters mean the following:
- down_threshold=20 indicate that when the CPU usage drops below 20%, the governor lowers the CPU frequency to conserve power.
- up_threshold=80 indicate that when the CPU usage exceeds 80%, the governor raises the CPU frequency to improve performance.
- sampling_rate=20000 indicate that the governor samples the CPU usage every 20,000 microseconds (or 20 milliseconds).

For more information on kernel modules, refer to Chapter 28, Managing kernel modules. Additionally, you can check the parameters of the installed modules on your system by looking at /sys/module/MODULE_NAME/parameters/.

cpu

The cpu plug-in manages and optimizes CPU-related settings to enhance performance, power savings, or a balance between the two. This plug-in allows fine-grained control over how the CPU operates, including setting the frequency governor, energy performance bias, and other parameters that directly influence the CPU's behavior and performance characteristics.

Certain commonly used parameters for the cpu plug-in are as follows:

priority: Sets the priority of CPU tuning operations. Higher values give the tuning operation a higher priority.
governor: Sets the CPU frequency scaling governor. Common options for this parameter include the following:
- performance: Forces the CPU to run at the maximum frequency, providing the best performance at the cost of higher power consumption.
- ondemand: Dynamically adjusts the CPU frequency based on system load, providing a balance between performance and power saving.
- conservative: Similar to the ondemand governor, but increases or decreases the CPU frequency more gradually. It is suitable for systems where power saving is important but performance should still be maintained.
energy_perf_bias: Hints to the CPU how to balance between power consumption and performance. Common options for this parameter include the following:
- performance: Bias towards maximum performance, possibly increasing power consumption.
- powersave: Bias towards power saving, possibly reducing performance.
- power: A more aggressive power-saving setting compared to powersave, but potentially less demanding compared to performance.
- normal: A balanced setting between performance and power saving.
force_latency: Controls the forced latency setting for the CPU. Lower values mean the system aggressively applies power-saving measures, possibly at the cost of increased latency. Higher values reduce the aggressiveness of power-saving measures, possibly improving responsiveness.
min_perf_pct: Specifies the minimum performance level as a percentage of the CPU's maximum performance. For example, a value of 100 means the CPU always runs at its maximum performance level. Lower values allow the CPU to run at lower performance levels when full performance is not needed, which can save power.

For example, a profile created for CPU-intensive workload, such as high-performance computing, can configure the plug-in for maximum CPU usage:

Example 13.8: TuneD plug-in configuration for CPU-intensive workload #

[cpu]
priority=1
governor=performance
energy_perf_bias=performance
force_latency=10
min_perf_pct=100

For more information on CPU performance scaling, refer to https://www.kernel.org/doc/Documentation/admin-guide/pm/cpufreq.rst.

audio

The audio plug-in tunes the system to optimize audio performance. This can involve adjusting CPU scheduling policies, setting CPU affinity, and configuring other system parameters to minimize audio latency, ensure smooth audio playback, and record real-time audio activities. For example:

Example 13.9: TuneD plug-in configuration for optimal audio performance #

[audio]
timeout=10 1
reset_controller=False 2

1

The timeout parameter specifies the time period (in seconds) for which the system should remain in the optimized state after the last audio activity is detected. This is intended to prevent the system from frequently switching back and forth between optimized and non-optimized states, which can cause instability or glitches in audio performance.

2

The reset_controller parameter manages the behavior of the audio module's power-saving controller. It allows you to enable or disable the resetting of the controller, which can influence how the system handles power management for audio devices. The parameter interacts with a system file located at /sys/module/AUDIO_MODULE_NAME/parameters/power_save_controller (for example, snd_hda_intel). By default, it is set to False.

video

The video plug-in provides options for tuning power-saving settings for certain graphics cards, particularly AMD Radeon cards. For example:

[video]
radeon_powersave=dpm-balanced

Common parameters used with this plug-in are as follows:

radeon_powersave: This parameter controls the power-saving mode of AMD Radeon graphics cards. It determines how the GPU handles power management, impacting performance and energy consumption. Configuration options used with this parameter include the following:
- default: The default power-saving profile, which is the default setting provided by the graphics driver.
- auto: Automatically adjusts power-saving settings based on current system usage.
- low: A low-power profile that reduces performance to save energy.
- mid: A medium-power profile that balances performance and power savings.
- high: A high-power profile that maximizes performance at the cost of higher power consumption.
- dynpm: Dynamic Power Management (DPM)—a mode that allows for dynamic adjustments based on the workload.
- dpm-battery: A DPM profile optimized for battery usage.
- dpm-balanced: A DPM profile that balances performance and power efficiency.
- dpm-performance: A DPM profile optimized for maximum performance.

disk

The disk plug-in tunes and optimizes the performance and power consumption of disk drives.

Common parameters and their possible values are as follows:

devices: Specifies on which disk devices the tuning parameters should be applied. By default, all devices are included. You can specify devices separated by comma.
dynamic: Boolean values that enable or disable dynamic tuning based on disk load. By default, it is set to True.
elevator: Configures the I/O scheduler (elevator) for the disk. Depending on the system's available schedulers, the possible options include noop, deadline or cfq.
apm: An integer (1–254) that sets the Advanced Power Management (APM) level of the disk. Higher values typically mean better performance, but higher power consumption.
spindown: The integer value for the spindown parameter is a special encoding used by the hdparm utility to set the spin-down timeout for a disk. For an explanation of the acceptable spin-down values, read about the -S option in the man page of hdparm.
readahead: An integer that sets the readahead value for the disk in kilobytes. You can change this to sectors by adding the appropriate suffix. For example, readahead = 8192 s. Ensure there is at least one space between the number and the suffix.
readahead_multiply: A float value that indicates the factor by which the value of the readahead parameter is multiplied.
scheduler_quantum: An integer that sets the number of I/O requests the scheduler handles simultaneously. Setting a higher quantum can improve throughput for sequential I/O operations by allowing more requests to be processed before switching. Conversely, a lower quantum can improve responsiveness for random I/O operations by reducing latency.

As an example, consider the following disk plug-in configuration in a TuneD profile:

Example 13.10: disk plug-in configuration in a TuneD profile #

[disk]
# Comma separated list of devices, all devices if commented out.
devices=sda,sdb

dynamic=True
elevator=deadline
apm=128
spindown=60

# Readahead adjusted to sectors by specifying relevant suffix.
# There must be at least one space between the number and suffix.
readahead=8192 s

readahead_multiply=1.5
scheduler_quantum=64

scsi_host

The scsi_host plug-in is used to manage power-saving settings for SCSI (Small Computer System Interface) host adapters on Linux systems. Commonly used parameters for this plug-in include the following:

alpm: The Aggressive Link Power Management (ALPM) setting controls the power management policy for Serial ATA (SATA) links. It can take different values to balance between power savings and performance. The possible options for this parameter include the following:
- min_power: This setting is more aggressive in terms of power savings. It puts the system into a lower power state when the SATA links are idle, which can save more power but may increase latency when accessing the disks.
- medium_power: This setting provides a balance between power savings and performance. It aims to reduce power consumption without impacting system performance too much.
- max_performance: This setting keeps SCSI hosts and devices in their highest power state. It prioritizes speed and responsiveness over energy efficiency, disabling power-saving features to minimize latency and maximize throughput.
For example, consider the following configuration that is appropriate for battery-powered devices, low-usage servers, and systems with long idle periods:
```
[scsi_host]
alpm=min_power
```
Note: Read/write of link power management policy by TuneD
The possible values are typically read from or written to the /sys/class/scsi_host/SCSI_HOST_NAME/link_power_management_policy file. The exact values may depend on what the kernel and the hardware support.

variables

The variables plug-in allows for the definition of variables that you can use across different TuneD profiles. This is particularly useful for setting parameters that may change based on the system environment or user preferences. By centralizing variable definitions, you can simplify profile management and enhance the flexibility of your tuning configurations.

Within the [variables] section of your profile configuration, you can specify variables using the following methods:

[variables]

include=PATH/TO/VARIABLE/CONFIGURATION/FILE 1

VAR_NAME=value 2

VAR_ANOTHER=${VAR_NAME_suffix} 3

VAR_DYNAMIC=$(uname -r) 4

1	Include a configuration file that already contains variable definitions for a certain context. For example, you can include the `/etc/tuned/cpu-partitioning-variables.conf` file to make variables such as `isolated_cores` and its values available for the ongoing profile configuration.
2	Define a variable directly by assigning a value.
3	Define a variable using another variable.
4	Define a variable using a command output.

For example, consider the following configuration for variables and its subsequent use in configuring other plug-ins for a profile configuration:

Example 13.11: Using dynamic variables for plug-in configurations in a TuneD profile #

[variables]

include=/etc/tuned/cpu-partitioning-variables.conf

SWAPPINESS_VALUE=10
NETWORK_INTERFACE=$(ip -o -4 route show to default | awk '{print $5}')

[sysctl]
vm.swappiness=${SWAPPINESS_VALUE}

[net]
interface=${NETWORK_INTERFACE}
disable_offload=yes

For more technically involved variable definitions, inspect the [variables] plug-in configurations available in the supported profile configuration files. To get a list of such profile configuration paths where the [variables] plug-in is included, run the following command:

> sudo grep -r '\[.*\]' /usr/lib/tuned/*/tuned.conf | sort -u | grep variables

sysctl

The sysctl plug-in offers a powerful way to customize several kernel parameters at runtime. This allows system administrators to optimize system performance, enhance security, and adjust network behavior without directly editing system files or running manual sysctl commands.

The sysctl plug-in accepts a wide range of parameters. Certain common categories include:

Kernel parameters (kernel.*)
Virtual Memory parameters (vm.*)
Network parameters (net.*)
File system parameters (fs.*)

where * is the wild card expression denoting permissible parameters for that category. When applying these parameters, TuneD might use the sysctl under the hood. For example:

> sysctl -q -w
CATEGORY.PARAMETER=VALUE

Common parameters and their possible values for the sysctl plug-in are summarized below:

Important: Understand the impact before modifying sysctl parameters

Modifying these parameters can considerably impact system behavior. It is crucial to understand their implications before making changes. Consult the official kernel documentation for detailed descriptions.

kernel.hung_task_timeout_secs: Time in seconds before a task is considered hung (default: 120).
kernel.numa_balancing: Enable (1) or disable (0) automatic NUMA balancing.
kernel.nmi_watchdog: Enable (1) or disable (0) the NMI watchdog.
kernel.timer_migration: Enable (1) or disable (0) timer migration.
kernel.sched_autogroup_enabled: Enable (1) or disable (0) scheduler autogrouping.
kernel.sched_min_granularity_ns: Minimum preemption granularity (in nanoseconds) for CPU-bound tasks.
kernel.sched_migration_cost_ns: The time (in nanoseconds) the scheduler considers a migrated process “cache hot”.
vm.stat_interval: Interval between updates of virtual machine statistics (default: 1).
vm.dirty_ratio: The percentage of system memory that can be filled with dirty pages before the processes must write them to disk.
vm.dirty_background_ratio: The percentage of system memory that can be filled with dirty pages before the background writeback process starts writing them to disk.
vm.swappiness: The tendency of the kernel to swap out idle processes. A swappiness of 0 instructs the kernel to keep the processes in the main memory for as long as possible.
vm.max_map_count: Maximum number of memory map areas a process may have.
net.core.busy_read: Number of busy loops for recvmsg (default: 50).
net.core.busy_poll: Number of busy loops for poll (default: 50).
net.ipv4.tcp_fastopen: Enable (1) or disable (0) TCP Fast Open.
net.ipv4.tcp_rmem: TCP read buffer size (minimum, default and maximum values separated by space).
net.ipv4.tcp_wmem: TCP write buffer size (minimum, default and maximum values separated by space).
net.ipv4.udp_mem: UDP buffer size (minimum, default and maximum values separated by space).
fs.aio-max-nr: Maximum number of allowed concurrent asynchronous I/O requests.
fs.file-max: Maximum number of file handles that the Linux kernel allocates.
fs.inotify.max_user_instances: Maximum number of inotify instances per user.
fs.inotify.max_user_watches: Maximum number of inotify watches per user.
fs.nr_open: Maximum number of file descriptors a process can have.
fs.suid_dumpable: Controls whether core dumps are produced for set-user-ID or set-group-ID programs.

As an example, consider the following configuration for the sysctl plug-in:

Example 13.12: Sample configuration for the sysctl plug-in in a TuneD profile #

[sysctl]

# Kernel Parameters
kernel.hung_task_timeout_secs = 600
kernel.nmi_watchdog = 0
kernel.timer_migration = 1
kernel.sched_autogroup_enabled = 1
kernel.sched_min_granularity_ns = 10000000
kernel.sched_migration_cost_ns = 5000000
kernel.sched_latency_ns = 60000000
kernel.sched_wakeup_granularity_ns = 2000000
kernel.numa_balancing = 0

# Virtual Machine Parameters
vm.stat_interval = 10
vm.dirty_ratio = 10
vm.dirty_background_ratio = 3
vm.swappiness = 10
vm.max_map_count = 800000

# Network Parameters
net.core.busy_read = 50
net.core.busy_poll = 50
net.ipv4.tcp_fastopen = 3
net.ipv4.tcp_rmem = "4096 87380 16777216"
net.ipv4.tcp_wmem = "4096 16384 16777216"
net.ipv4.udp_mem = "3145728 4194304 16777216"

# Filesystem Parameters
fs.aio-max-nr = 1048576
fs.file-max = 2097152
fs.inotify.max_user_instances = 1024
fs.inotify.max_user_watches = 524288
fs.nr_open = 1048576
fs.suid_dumpable = 1

Tip: Best practices for changing sysctl settings

Optimal sysctl settings can vary greatly depending on the specific use case, hardware and workload of your system. It is recommended to test changes thoroughly and monitor system performance after applying new sysctl configurations.

sysfs

The sysfs plug-in accepts any valid file path under the system file system, or the /sys/ directory. The plug-in checks whether a file path is valid and can read and write the values in the files that are part of the configuration. For example, consider the following configuration of the sysfs plug-in:

Example 13.13: sysfs plug-in configuration in a TuneD profile #

[sysfs]
/sys/bus/workqueue/devices/writeback/cpumask = 2,6 1
/sys/devices/virtual/workqueue/cpumask = 3-5 2
/sys/devices/system/machinecheck/machinecheck*/ignore_ce = 1 3

1	Single CPUs separated by comma. Only those CPUs that are not isolated using the isolcpus kernel boot parameter are allowed. To check the CPUs that are already isolated, run the `grep isolcpus /proc/cmdline` command. To check the total number of CPUs in your system, run the `lscpu \| grep "^CPU(s):"` command.
2	Range of CPUs. Only those CPUs that are not isolated using the isolcpus kernel boot parameter are allowed. To check the CPUs that are already isolated, run the command `grep isolcpus /proc/cmdline`. To check the total number of CPUs in your system, run the `lscpu \| grep "^CPU(s):"` command.
3	Corrected Errors (CEs) are hardware errors that the system has detected and corrected automatically. The `ignore_ce` attribute is a sysfs setting that controls whether the system must report these corrected errors. When `ignore_ce` is set to `1`, the system ignores corrected errors, meaning they are not logged or reported to the operating system's error handling mechanisms. When `ignore_ce` is set to `0` (the default value), corrected errors are reported and logged by the system, allowing administrators to monitor them.

systemd

The systemd plug-in focuses on configuring the parameters of systemd, which is the system and service manager for SUSE Linux Enterprise Server. For example, consider the plug-in configuration for CPU affinity of systemd processes:

Example 13.14: systemd plug-in configuration in a TuneD profile #

[systemd]
cpu_affinity=0,1,2 1

1

Binds the systemd services to multiple specified CPU cores. By default, it is None. In this example, the services are configured to run on CPU cores 0, 1, and 2. Alternate ways of passing the values include passing a range of CPU cores, such as 0-2. However, you cannot pass on the CPU cores as values which you have declared as isolated_cores in the file /etc/tuned/cpu-partitioning-variables.conf. Configuring the cpu_affinity parameter in the plug-in is equivalent to configuring the CPUAffinity in the systemd configuration file /etc/systemd/system.conf.

script

The script plug-in allows users to execute custom scripts that TuneD runs at different stages. System administrators can use it to automate several system configurations and optimizations by specifying paths to such scripts. Common parameters and their possible values include the following:

priority: An integer value that sets the priority level for the script. TuneD executes scripts based on their priority, with lower numbers indicating higher priority. So, a priority of 5 means this script has a low priority compared to scripts with a priority number lower than 5.
script: This specifies the path to the script that TuneD executes. You can either provide the absolute path to the script as its value, or use the PROFILE_DIR variable to pass the relative path to the script.

For example, consider the following use of a relative script path:

Example 13.15: Using variables for including a relative script path in a TuneD profile #

[script]
priority=5
script=${i:PROFILE_DIR}/script.sh

Tip: Resource for definition of variables

For a list of useful variables, inspect the constants defined in the source file https://github.com/redhat-performance/tuned/blob/v2.10.0/tuned/consts.py.

scheduler

The scheduler plug-in is used to manage the isolation of CPU cores and the selection of processes for management based on adding to an approved list or a blocklist. This plug-in is primarily concerned with isolating specific CPU cores and managing which processes should or should not be managed by the scheduler. Commonly used parameters and their possible values include the following:

isolated_cores: Isolates specific CPU cores from the general scheduler. Processes can be pinned to these isolated cores to ensure they run without interference from other system processes. To pass values to this parameter, use comma-separated integers representing the cores, or the bitmask of the integers in the hexadecimal format. For example, isolated_cores=0,1 can also be represented by 0x3 in a more compact manner.
ps_whitelist: A list of allowed process names that the scheduler plug-in is empowered to manage. Only processes matching this pattern are considered for scheduling adjustments. Pass regular expressions of process names as values to this parameter. For example, .* matches all processes, and ^bash$ matches only the bash process.
ps_blacklist: A list of process names that the plug-in excludes from management. Processes matching this pattern are not adjusted by the plug-in. Pass regular expressions of process names as values to this parameter. For example, .* matches all processes, and ^idle$ matches only the idle process.

For example, consider the following configuration for the scheduler plug-in:

Example 13.16: scheduler plug-in configuration in a TuneD profile #

isolated_cores=0x3
ps_whitelist=.*
ps_blacklist=^idle$;.*pmd.*;.*PMD.*;^DPDK;.*qemu-kvm.*

bootloader

The bootloader plug-in is used to apply performance profiles that require changes to the boot parameters of the system. These changes are made in the boot loader configuration file (typically GRUB 2 configuration) and are applied when the system boots up. This plug-in is particularly useful for optimizing system performance by setting specific kernel parameters, such as those controlling CPU isolation or power management, as well as other boot-time settings that can affect the overall system behavior and performance.

Common parameters and their values are summarized below:

grub2_cfg_file: Specifies the GRUB 2 configuration file to modify. If not provided, the plug-in uses the default GRUB2 configuration files located in the system.
initrd_dst_img: Sets the destination path for the initrd image. If specified, the initrd image is copied to this location. The path must be absolute, and if it is not provided, the default boot directory is used.
initrd_add_img: Adds the path to an initrd image in the GRUB 2 configuration, so that custom initrd images can be used during the boot process.
initrd_add_dir: Adds a directory to be included in the initrd image. This parameter specifies the path to a directory whose contents are packaged into an initrd image and included in the boot configuration. This is useful for adding custom modules or scripts to the initrd.
initrd_remove_dir: A boolean option to specify whether to remove the directory specified in initrd_add_dir after it has been packaged into the initrd image. If set to True, the source directory is deleted after the initrd image is created.
cmdline: Specifies additional kernel command-line parameters to be added to the GRUB 2 configuration. This allows the addition of custom kernel parameters that can optimize system performance or behavior based on the specific needs of the workload.

As an example, consider the following configuration for the bootloader plug-in:

Example 13.17: bootloader plug-in configuration in a TuneD profile #

[bootloader]
cmdline="isolcpus=1-3 nohz_full=1-3 intel_pstate=disable"
initrd_add_img="/path/to/custom-initrd.img"
initrd_add_dir="/path/to/custom-initrd-dir"
initrd_remove_dir=True
initrd_dst_img="/boot/initrd-custom.img"
grub2_cfg_file="/etc/grub2.cfg"

net

The net plug-in is used to configure several parameters for optimizing network performance. Common parameters and their values used with this plug-in are summarized below:

devices: Specifies a comma-separated list of the network device names. For example, devices=eth0,eth1. By default, the settings are applied on all network devices.
dynamic: Boolean values (true/false) that enable or disable dynamic tuning based on network load.
wake_on_lan: Configure Wake-on-LAN (WoL) settings using any combination of the following characters:
- p: Wake on PHY activity.
- u: Wake on unicast messages.
- m: Wake on multicast messages.
- b: Wake on broadcast messages.
- a: Wake on ARP.
- g: Wake on MagicPacket^TM.
- s: Enable SecureOn^TM for MagicPacket^TM.
- d: Disable WoL.
nf_conntrack_hashsize: Integer value setting the size of the connection-tracking hash table.
features: A dictionary of network device feature names and their desired states. For example, tx-checksum: off, sg: on.
coalesce: A dictionary of packet coalescing parameters.
- adaptive-rx and adaptive-tx have the possible values on or off.
- The following ones have integer values: rx-usecs, rx-frames, rx-usecs-irq, rx-frames-irq, tx-usecs, tx-frames, tx-usecs-irq, tx-frames-irq, stats-block-usecs, pkt-rate-low, rx-usecs-low, rx-frames-low, tx-usecs-low, tx-frames-low, pkt-rate-high, rx-usecs-high, rx-frames-high, tx-usecs-high, tx-frames-high, sample-interval
pause: A dictionary of pause frame parameters. The following pause frame parameters have on or off values: autoneg, rx and tx.
ring: A dictionary of ring buffer sizes. Each of the following ring buffer size parameter has integer values: rx, rx-mini, rx-jumbo and tx.

As an example of configuring network device parameters, consider the following:

Example 13.18: net plug-in configuration in a TuneD profile #

[net]
devices=eth0,eth1
dynamic=true
wake_on_lan=g
nf_conntrack_hashsize=16384
features=tx-checksum:off, sg:on
coalesce=adaptive-rx:on, rx-usecs:50, rx-frames:32
pause=autoneg:on, rx:on, tx:off
ring=rx:2048, tx:1024

vm

The vm plug-in optimizes memory management in virtualized environments. It provides mechanisms for tuning memory-related parameters, specifically focusing on the management of Transparent Hugepages (THP). Commonly used parameters and their values for this plug-in include the following:

transparent_hugepage or transparent_hugepages: Often used interchangeably, these parameters are aliases for each other and perform the function of controlling the behavior of Transparent Hugepages. The common properties and values associated with this parameter are as follows:
- enabled: Controls the overall enabling of transparent hugepages. Possible values are always, madvise and never.
- defrag: Determines when, if defragmentation should occur. Possible values are always, defer, madvise, defer+madvise and never.
- khugepaged: Configures settings related to the khugepaged daemon, including options such as scan_sleep_millisecs and alloc_sleep_millisecs.

For example, consider the following configuration of the vm plug-in in a TuneD profile:

Example 13.19: vm plug-in configuration in a TuneD profile #

[vm]
transparent_hugepages.enabled=always
transparent_hugepage.defrag=always
transparent_hugepages.khugepaged.scan_sleep_millisecs=10000

eeepc_she

The eeepc_she plug-in enhances power management on ASUS EeePC netbooks, specifically those equipped with the Super Hybrid Engine (SHE) technology. It optimizes system performance by dynamically adjusting CPU frequencies and power states to achieve a balance between energy efficiency and processing power. The commonly used parameters and their values are as follows:

load_threshold_normal: Threshold for load to switch to normal mode. Default value is 0.6.
load_threshold_powersave: Threshold for load to switch to powersave mode. Default value is 0.4.
she_powersave: Value to set SHE to power saving mode. Default value is 2.
she_normal: Value to set SHE to normal mode. Default value is 1.

13.7 More information #

For more information, refer to the following resources:

The official Web site of the TuneD project: https://tuned-project.org/
Source code repository on GitHub: https://github.com/redhat-performance/tuned. You may find the following resources to be particularly helpful:
- Configuration files for several profiles are available at https://github.com/redhat-performance/tuned/tree/v2.10.0/profiles. These configuration examples can provide a good starting point for creating a custom profile that is not available as part of the tuned package for SUSE Linux Enterprise Server.
- If you are interested in implementing the plug-ins that monitor and dynamically tune the system based on values provided in the profiles, the source code is available at https://github.com/redhat-performance/tuned/tree/v2.10.0/tuned/plugins.

Tip: Refer to appropriate version of TuneD source code

Check for the version of tuned in your SUSE Linux Enterprise Server system by running the tuned --version command. On the GitHub repository, select the corresponding branch or tag for inspecting the source code of the specific tuned version installed on your system.