diff --git a/xml/book_tuning.xml b/xml/book_tuning.xml
index a143086542..72b5c27586 100644
--- a/xml/book_tuning.xml
+++ b/xml/book_tuning.xml
@@ -92,6 +92,7 @@
+
diff --git a/xml/product-entities.ent b/xml/product-entities.ent
index 0449b8b2f8..56655590fd 100644
--- a/xml/product-entities.ent
+++ b/xml/product-entities.ent
@@ -53,4 +53,8 @@
-
\ No newline at end of file
+
+
+
+
+
diff --git a/xml/tuning_tuned.xml b/xml/tuning_tuned.xml
new file mode 100644
index 0000000000..b2c5aa8921
--- /dev/null
+++ b/xml/tuning_tuned.xml
@@ -0,0 +1,2516 @@
+
+
+ %entities;
+]>
+
+ Adaptive and dynamic tuning using &tunedapp;
+
+
+
+ &tunedapp; 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. &tunedapp; offers predefined
+ tuning profiles tailored for common use cases such as servers and virtual machines, as well
+ as the ability to create custom profiles. &tunedapp; 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.
+
+
+
+
+ yes
+
+
+
+ Introduction to &tunedapp;
+
+
+ The &tunedapp; application monitors and adjusts system settings on certain &sles; workloads
+ based on usage of different system resources, such as the CPU and the disk. The primary goal
+ of &tunedapp; 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 &tunedapp;
+ 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.
+
+
+
+ Components of &tunedapp;
+
+
+ The &tunedapp; 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 &tunedapp;
+ using systemctl. By default, when invoked from the terminal
+ manually, tuned runs as a normal process. However, you can use
+ the 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;.
+
+&prompt.user;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
+ .
+
+
+
+
+ Profiles
+
+
+ A &tunedapp; 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 .
+
+
+
+
+ Plug-ins
+
+
+ A &tunedapp; 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 .
+
+
+
+
+ Extension scripts
+
+
+ System administrators can extend the ecosystem of &tunedapp; 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 .
+
+
+
+
+
+
+ Managing &tunedapp;
+
+
+ This section covers the essential tasks for managing the &tuned; service lifecycle on &sles;.
+ 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.
+
+
+
+ Installing &tunedapp;
+
+ The recommended way to install a supported version of &tunedapp; is to install the
+ tuned package using the zypper package manager.
+
+
+ <package>tuned</package> is available only for &sles;
+
+ The tuned package is available only in the official &sles;
+ repositories. There is no equivalent package available in the official &sled;
+ repositories.
+
+
+
+
+
+ To install the &tuned; daemon, command-line utilities, profiles and plug-ins, run the
+ following command:
+
+&prompt.sudo;zypper install -y tuned
+
+
+
+ Verify the installation by running the following commands:
+
+&prompt.user;tuned --help
+&prompt.user;tuned-adm --help
+
+
+
+ To know more, read the man pages for tuned,
+ tuned-adm, tuned-profiles and
+ tuned.conf.
+
+
+
+
+
+
+ Enabling &tuned;
+
+ To enable &tuned;, perform the following procedure:
+
+
+
+
+ Check the status of the &tuned; service:
+
+&prompt.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:
+
+&prompt.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.
+
+
+
+
+
+
+ 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:
+
+&prompt.sudo;systemctl start tuned
+
+ 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 and
+ .
+
+
+
+
+
+ Start &tuned; as a normal process connected to the TTY only for the current
+ session:
+
+&prompt.sudo;tuned
+
+ Running the <command>tuned</command> 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:
+
+&prompt.sudo;systemctl enable --now tuned
+
+
+
+
+
+
+
+ Disabling &tuned;
+
+ As a best practice, perform the following steps to disable &tuned;:
+
+
+
+
+ Check the status of the &tuned; systemd service:
+
+&prompt.sudo;systemctl status tuned
+
+
+
+ Turn off or disable all tuning settings applied earlier:
+
+&prompt.sudo;tuned-adm off
+
+
+
+ If the status of the &tuned; daemon is active, stop the daemon:
+
+&prompt.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:
+
+&prompt.sudo;systemctl disable tuned
+
+
+
+ Simultaneously disable the &tuned; systemd service and stop the &tuned; daemon
+ immediately:
+
+&prompt.sudo;systemctl disable --now tuned
+
+
+
+
+
+
+
+ &tunedapp; profiles
+
+
+ &tunedapp; optimizes &sles; 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 &tunedapp;
+ profiles.
+
+
+
+ Supported &tunedapp; profiles
+
+ &sles; 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 &tunedapp; profile configuration files, see the following sections:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Managing &tunedapp; profiles
+
+ If you just want to activate a profile, pass the profile name to the
+ tuned command:
+
+&prompt.sudo;tuned --profile PROFILE_NAME
+
+ However, the best practice for managing the lifecycle of &tunedapp; profiles is to use the
+ tuned-adm command-line tool.
+
+
+ Using <command>tuned-adm</command>
+
+ You can use the tuned-adm command to perform the following tasks:
+
+
+
+
+ List all available profiles.
+
+&prompt.sudo;tuned-adm list
+
+
+
+ List active profile.
+
+&prompt.sudo;tuned-adm active
+
+
+
+ Display information about the current profile.
+
+&prompt.sudo;tuned-adm profile_info
+
+
+
+ Display information about a specified profile.
+
+&prompt.sudo;tuned-adm profile_info PROFILE_NAME
+
+
+
+ Recommend a profile based on the current system usage.
+
+&prompt.sudo;tuned-adm recommend
+
+ By default, &tunedapp; in &sles; 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.
+
+&prompt.sudo;tuned-adm profile_mode
+
+
+
+ Select a profile automatically, and switch to the recommended profile.
+
+&prompt.sudo;tuned-adm auto_profile
+
+
+
+ Manually switch to a specified profile.
+
+&prompt.sudo;tuned-adm profile PROFILE_NAME
+
+
+
+ Verify that a profile has been successfully applied, and the system state matches the
+ profile's configurations.
+
+&prompt.sudo;tuned-adm verify
+
+
+
+ Turn off all tunings.
+
+&prompt.sudo;tuned-adm off
+
+
+
+ For more information on tuned-adm, see its help information or man
+ page.
+
+&prompt.sudo;tuned-adm --help
+&prompt.user;man tuned-adm
+
+
+ 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
+
+
+
+
+ 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:
+
+
+ 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:
+
+&prompt.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:
+
+
+ &tunedapp; 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:
+
+&prompt.sudo;tuned-adm profile CUSTOM_PROFILE_NAME
+
+
+
+
+
+
+
+ &tunedapp; configuration
+
+
+ Configuration files form the foundation of &tunedapp; and its profiles. In &sles;, the
+ /etc/tuned/ file is the main configuration file for the &tuned; daemon.
+ This file contains global settings that affect the overall behavior of &tunedapp;.
+
+
+
+ Also, each &tunedapp; 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 &tunedapp; 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 &tunedapp; plug-ins, see .
+
+
+
+ Global &tunedapp; 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:
+
+
+ Default global &tunedapp; configuration
+
+daemon = 1
+
+dynamic_tuning = 1
+
+sleep_interval = 1
+
+update_interval = 10
+
+recommend_command = 1
+
+reapply_sysctl = 1
+
+default_instance_priority = 0
+
+udev_buffer_size = 1MB
+
+log_file_count = 2
+
+log_file_max_size = 1MB
+
+
+
+
+
+ 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 &tunedapp;'s functionality to
+ static tuning only.
+
+
+
+
+ Enables or disables dynamic tuning of devices. When set to 1,
+ &tunedapp; 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.
+
+
+
+
+ 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.
+
+
+
+
+ Sets the interval in seconds for updating dynamic tunings. This value must be a
+ multiple of sleep_interval.
+
+
+
+
+ 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.
+
+
+
+
+ Determines whether system sysctl settings from files such as
+ /etc/sysctl.conf and /etc/sysctl.d should be
+ reapplied after &tunedapp; sysctl settings are applied. When enabled by setting to 1,
+ system sysctl settings override &tunedapp; sysctl settings.
+
+
+
+
+ Specifies the default priority assigned to the &tunedapp; 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
+ /var/log/tuned/. This helps in log rotation, where older logs are
+ archived and new logs are created.
+
+
+
+
+ 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.
+
+
+
+
+
+ Modify the values of the global settings in /etc/tuned/ only when
+ you are sure of its effects on the behavior of &tunedapp;.
+
+
+
+ For a detailed overview of the main &tunedapp; configuration file, read its man page:
+
+&prompt.user;man 5 tuned-main.conf
+
+
+
+ Supported profile configuration
+
+ Every supported &tunedapp; 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.
+
+
+ General syntax of &tunedapp; 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 &tunedapp; configuration files, read its man page:
+
+&prompt.user;man 5 tuned.conf
+
+
+
+
+ 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.
+
+
+ Path to &tunedapp; 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/.
+
+
+
+
+ &suse; does not support any profile that is not part of the supported profiles supplied
+ with the tuned from official &sles; repositories. Create and apply a
+ custom profile on a production system only if you are sure of its effect.
+
+
+
+ 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.
+
+
+ Merging <literal>balanced</literal> and <literal>powersave</literal> &tunedapp; profiles
+
+
+
+ Create the path for the custom profile:
+
+&prompt.sudo;mkdir /etc/tuned/CUSTOM_PROFILE_NAME
+
+
+
+ Create a profile configuration file in the following directory:
+
+&prompt.sudo;vi /etc/tuned/CUSTOM_PROFILE_NAME/tuned.conf
+
+
+
+ Add the following configuration to the file:
+
+
+ Merged configuration for <literal>balanced</literal> and <literal>powersave</literal> &tunedapp; profiles
+
+[main]
+include=balanced
+
+[cpu]
+governor=powersave
+energy_perf_bias=powersave
+
+[disk]
+# Inherit settings from balanced profile
+
+[sysctl]
+vm.swappiness=10
+
+
+
+
+
+ Include the balanced profile as a base, which is suitable
+ for general purpose use.
+
+
+
+
+ Overrides CPU parameters such as governor and
+ energy-perf-bias to powersave.
+
+
+
+
+ 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 and powersave profiles.
+
+&prompt.sudo;tuned-adm profile CUSTOM_PROFILE_NAME
+
+
+
+
+
+
+
+ &tunedapp; plug-ins
+
+
+ &tunedapp; plug-ins are modular components that extend the functionality of the &tunedapp;
+ 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, &tunedapp; 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 &tunedapp; profile configuration files is as
+ follows:
+
+
+
+...
+[PLUGIN-NAME]
+PARAMETER_1=VALUE_1
+PARAMETER_2=VALUE_2
+...
+
+
+
+ The supported &tunedapp; profiles for &sles; have multiple plug-ins and their parameters
+ included within them. To see a list of all such plug-ins, run the following command:
+
+
+&prompt.sudo;grep -r '\[.*\]' /usr/lib/tuned/*/tuned.conf | sort -u
+
+
+ Supported &tunedapp; plug-ins
+
+ On &sles;, the following &tunedapp; plug-ins are supported:
+
+
+
+ main
+
+
+ main is not a plug-in, but a special section in the &tunedapp;
+ 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.
+
+
+ Impact of updated &tunedapp; 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, &tunedapp; 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_PARAMETERS
+
+
+
+
+ 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:
+
+
+ Automatic reload of kernel modules by &tunedapp;
+
+[modules]
+cpufreq_conservative=+r,down_threshold=20,up_threshold=80,sampling_rate=20000
+
+
+
+
+
+
+
+ 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 &tunedapp; keeps track of how many profiles are
+ using this module. When a module with +r is loaded,
+ &tunedapp; 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 .
+ 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:
+
+
+ &tunedapp; 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
+ .
+
+
+
+
+ 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:
+
+
+ &tunedapp; plug-in configuration for optimal audio performance
+
+[audio]
+timeout=10
+reset_controller=False
+
+
+
+
+
+ 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 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
+ 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 &tunedapp; profile:
+
+
+ <literal>disk</literal> plug-in configuration in a &tunedapp; 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
+
+
+ Read/write of link power management policy by &tunedapp;
+
+ 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 &tunedapp; 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
+
+VAR_NAME=value
+
+VAR_ANOTHER=${VAR_NAME_suffix}
+
+VAR_DYNAMIC=$(uname -r)
+
+
+
+
+ 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.
+
+
+
+
+ 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:
+
+
+ Using dynamic variables for plug-in configurations in a &tunedapp; 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:
+
+&prompt.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, &tunedapp; might use
+ the sysctl under the hood. For example:
+
+&prompt.user;sysctl -q -w
+CATEGORY.PARAMETER=VALUE
+
+ Common parameters and their possible values for the sysctl plug-in
+ are summarized below:
+
+
+ Understand the impact before modifying <literal>sysctl</literal> 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:
+
+
+ Sample configuration for the <literal>sysctl</literal> plug-in in a &tunedapp; 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
+
+
+
+ Best practices for changing <literal>sysctl</literal> 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:
+
+
+ <literal>sysfs</literal> plug-in configuration in a &tunedapp; profile
+
+[sysfs]
+/sys/bus/workqueue/devices/writeback/cpumask = 2,6
+/sys/devices/virtual/workqueue/cpumask = 3-5
+/sys/devices/system/machinecheck/machinecheck*/ignore_ce = 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.
+
+
+
+
+ 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.
+
+
+
+
+ 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 &sles;. For example, consider
+ the plug-in configuration for CPU affinity of &systemd; processes:
+
+
+ <literal>systemd</literal> plug-in configuration in a &tunedapp; profile
+
+[systemd]
+cpu_affinity=0,1,2
+
+
+
+
+ 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
+ &tunedapp; 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. &tunedapp; 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
+ &tunedapp; 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:
+
+
+ Using variables for including a relative script path in a &tunedapp; profile
+
+[script]
+priority=5
+script=${i:PROFILE_DIR}/script.sh
+
+
+
+ Resource for definition of variables
+
+ For a list of useful variables, inspect the constants defined in the source file
+ .
+
+
+
+
+
+ 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:
+
+
+ <literal>scheduler</literal> plug-in configuration in a &tunedapp; 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; 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; 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; 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; 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:
+
+
+ <literal>bootloader</literal> plug-in configuration in a &tunedapp; 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 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:
+
+
+ <literal>net</literal> plug-in configuration in a &tunedapp; 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 &tunedapp; profile:
+
+
+ <literal>vm</literal> plug-in configuration in a &tunedapp; 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.
+
+
+
+
+
+
+
+
+
+ More information
+
+
+ For more information, refer to the following resources:
+
+
+
+
+
+ The official Web site of the &tunedapp; project:
+
+
+
+
+
+ Source code repository on GitHub:
+ . You may
+ find the following resources to be particularly helpful:
+
+
+
+
+ Configuration files for several profiles are available at
+ .
+ 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
+ &sles;.
+
+
+
+
+ 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
+ .
+
+
+
+
+
+
+
+ Refer to appropriate version of &tunedapp; source code
+
+ Check for the version of &tuned; in your &sles; 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.
+
+
+
+