13 Adaptive and dynamic tuning using TuneD #
TuneD is a daemon for Linux systems that monitors CPU and disk usage and adjusts
specific settings to optimize system performance under certain workloads. Other system
settings, such as those configured via sysctl
, are applied when the
service starts, and remain static unless manually reloaded. TuneD offers predefined
tuning profiles tailored for common use cases such as servers and virtual machines, as well
as the ability to create custom profiles. TuneD leverages several tuning plug-ins that
interact with underlying Linux subsystems to tune the CPU, disk I/O, networking, virtual
memory, power management, and other components.
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
daemonThe 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 usingsystemctl
. 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 thetuned
daemon usingtuned-adm
, see Section 13.4.2.1, “Usingtuned-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.
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
andtuned.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:Start
tuned
as a background process and let systemd manage the states of the daemon:>
sudo
systemctl start tuned
Note: Profile run bytuned
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 thetuned-adm
command. For more information, see Section 13.4, “TuneD profiles” and Section 13.6, “TuneD plug-ins”.Start
tuned
as a normal process connected to the TTY only for the current session:>
sudo
tuned
Tip: Running thetuned
commandYou 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 thetuned
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
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:
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
Specifies whether to use the | |
Enables or disables dynamic tuning of devices. When set to | |
Defines the interval in seconds that the | |
Sets the interval in seconds for updating dynamic tunings. This value must be a
multiple of | |
Controls the availability of the | |
Determines whether system sysctl settings from files such as
| |
Specifies the default priority assigned to the TuneD instances. Higher values indicate a higher priority. | |
Defines the buffer size for udev events. This setting helps manage the amount of data processed from udev. | |
Sets the number of log files to keep in the directory
| |
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
|
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.
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/.
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.
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 forbalanced
andpowersave
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
Include the
balanced
profile as a base, which is suitable for general purpose use.Overrides CPU parameters such as
governor
andenergy-perf-bias
topowersave
.Inherit disk settings from the
balanced
profile.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
andpowersave
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 profileWhen 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
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
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 theondemand
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 topowersave
, but potentially less demanding compared toperformance
.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
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.
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 toFalse
.- 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
orcfq
.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 TuneDThe 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
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 asisolated_cores
and its values available for the ongoing profile configuration.Define a variable directly by assigning a value.
Define a variable using another variable.
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 thesysctl
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 modifyingsysctl
parametersModifying 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 thesysctl
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 changingsysctl
settingsOptimal 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 thesysfs
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
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 thelscpu | grep "^CPU(s):"
command.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 thelscpu | grep "^CPU(s):"
command.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. Whenignore_ce
is set to1
, the system ignores corrected errors, meaning they are not logged or reported to the operating system's error handling mechanisms. Whenignore_ce
is set to0
(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 ofsystemd
, which is the system and service manager for SUSE Linux Enterprise Server. For example, consider the plug-in configuration for CPU affinity ofsystemd
processes:Example 13.14:systemd
plug-in configuration in a TuneD profile #[systemd] cpu_affinity=0,1,2 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 cores0
,1
, and2
. Alternate ways of passing the values include passing a range of CPU cores, such as0-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 thesystemd
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 than5
.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 variablesFor 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 by0x3
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 thebash
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 theidle
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 MagicPacketTM.s
: Enable SecureOnTM for MagicPacketTM.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
andadaptive-tx
have the possible valueson
oroff
.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
oroff
values:autoneg
,rx
andtx
.ring: A dictionary of ring buffer sizes. Each of the following ring buffer size parameter has integer values:
rx
,rx-mini
,rx-jumbo
andtx
.
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 arealways
,madvise
andnever
.defrag
: Determines when, if defragmentation should occur. Possible values arealways
,defer
,madvise
,defer+madvise
andnever
.khugepaged
: Configures settings related to the khugepaged daemon, including options such asscan_sleep_millisecs
andalloc_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.
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.