When the default settings fight your workload
You just finished setting up a Fedora workstation for audio production, but your DAW is dropping audio buffers every time you add a heavy reverb chain. Or you installed Fedora on a virtual machine and the disk I/O feels sluggish compared to your host system. You checked the CPU governor and saw it is idling, but you need the processor to stay responsive under load. You do not want to manually tweak /proc/sys parameters or write complex systemd service files to manage kernel settings. You need a way to tell the kernel, "I am doing X, make the system behave for that."
How tuned works under the hood
tuned is a daemon that reads a configuration profile and applies a set of kernel parameters, CPU frequency governors, I/O scheduler settings, and power management rules. It runs in the background and watches for hardware changes. If you plug in a power adapter, tuned can switch profiles automatically. If you create a VM, tuned detects the virtualization and can adjust accordingly.
Think of tuned like a scene recall system in a lighting console. Instead of manually adjusting every dimmer and color channel for each song, you save a scene. When the song changes, you hit the scene button, and the lights snap to the right configuration. tuned does this for kernel parameters. You pick a profile, and the daemon applies a bundle of optimizations tailored to that workload.
Profiles are just text files that define these settings. Fedora ships with a library of profiles in /usr/lib/tuned/. You should never edit files there. Package updates will overwrite your changes. If you need a custom profile, copy it to /etc/tuned/. The daemon checks /etc/ first, so your copy takes precedence. This follows the standard Linux convention: /usr/lib/ contains package-managed files, /etc/ contains user modifications.
Profiles use plugins to apply changes. The sysctl plugin modifies kernel parameters. The cpu plugin changes frequency governors and turbo boost settings. The disk plugin sets I/O schedulers and read-ahead values. The network plugin tunes buffer sizes and offloading features. Understanding plugins helps you debug. If a profile is not working, check which plugins are active. If the cpu plugin is missing, the governor will not change.
Apply a profile to match your hardware
Here is how to see what profiles are available and apply one to your system.
# List all available profiles and highlight the currently active one
sudo tuned-adm list
The output shows every profile installed on your system. The one marked as active is the one currently driving your kernel parameters. Fedora usually defaults to balanced on desktops and throughput-performance on servers. This default is a safe middle ground. It keeps the system responsive without draining battery or wasting power.
If you are unsure which profile fits your hardware, tuned can analyze the system and suggest a recommendation.
# Ask tuned to analyze hardware and suggest the best profile
sudo tuned-adm recommend
This command checks for virtualization, CPU type, and disk configuration. It returns a profile name. It is not mandatory. You can override the recommendation. But it saves time when you are setting up a new server and are not sure which profile fits.
Run this command to switch profiles immediately. tuned applies the changes on the fly. You do not need to reboot. The daemon sends sysctl commands and updates CPU governors instantly.
# Switch to the latency-performance profile for real-time audio work
sudo tuned-adm active latency-performance
If you make a mistake, you can switch back just as fast. The transition is seamless for most settings. Some network buffer changes might affect active connections, but the kernel handles the update without dropping the stack.
Apply the profile and check the governor. If the governor did not change, the profile did not load. Check journalctl.
Confirm the changes took effect
Verify the change took effect. The status command prints the active profile and lists the plugins that are currently modifying the system.
# Show the active profile and the plugins it is using
sudo tuned-adm status
Look for the list of active plugins. If you see cpu and sysctl, the profile is applying CPU and kernel settings. If the list is empty, the profile might be misconfigured or the plugins failed to load.
Check a specific parameter to confirm the kernel is following the profile.
# Check the CPU governor to confirm the profile changed it
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
If you switched to latency-performance, this should print performance. If you are on balanced, it might print schedutil or powersave depending on your hardware. This confirms the kernel is actually following the profile's instructions.
If you manually run sysctl -w vm.swappiness=10, tuned might reset it. tuned runs periodically and enforces the profile settings. If you want a permanent manual change, add it to a tuned profile. Do not fight tuned with manual commands. The daemon will win.
Common errors and configuration traps
If tuned-adm active returns an error, the service might not be running. Fedora enables tuned by default, but a manual installation or a broken update could disable it. Check the service state first.
# Check if the tuned daemon is running and enabled
sudo systemctl status tuned
If the service is inactive, start it. If it fails to start, check the logs. tuned errors often show up as SELinux denials if you are running a custom profile with unusual permissions.
# View recent logs for the tuned service to find the failure reason
sudo journalctl -xeu tuned
Look for lines starting with setroubleshoot or SELinux. If you see a denial, read the summary. It usually tells you exactly which file or operation was blocked. Do not disable SELinux. Fix the context or report the bug.
Applying the wrong profile for your hardware causes subtle performance issues. Using virtual-guest on bare metal hardware disables features like CPU frequency scaling that you actually need on physical hardware. It assumes the hypervisor is managing the resources. Using it on bare metal can make your system slower and less responsive. Always match the profile to the environment.
Copy to /etc before editing. Editing /usr/lib is a one-way ticket to broken upgrades.
Create a custom profile for unique needs
The built-in profiles cover most use cases. If you need a tweak that does not fit, create a custom profile. Copy the base profile to /etc/tuned/.
# Copy the latency profile to /etc so you can modify it safely
sudo cp -r /usr/lib/tuned/latency-performance /etc/tuned/custom-audio
Edit the tuned.conf inside the new directory. Add your custom sysctl settings or plugin configurations.
# /etc/tuned/custom-audio/tuned.conf
# Inherit settings from the base profile to avoid rewriting everything
[main]
include=latency-performance
# Add custom sysctl parameters for your specific audio interface
[sysctl]
vm.swappiness=1
net.core.rmem_max=134217728
The include directive is powerful. It lets you inherit all settings from an existing profile and only override what you need. This keeps your custom profile small and maintainable. When the base profile gets updated in a package upgrade, your custom profile automatically picks up the improvements.
If you have many small tweaks, putting them all in tuned.conf gets messy. Use the profile.d directory. Create a directory named profile.d inside your custom profile. Add files with .conf extension. tuned reads all files in profile.d and merges them.
# Create a snippet directory for modular configuration
sudo mkdir -p /etc/tuned/custom-audio/profile.d
This keeps your configuration organized. You can have one file for audio settings, one for network, and one for disk. It makes maintenance easier.
Apply your custom profile.
# Activate your new custom profile
sudo tuned-adm active custom-audio
Match the profile to the hardware. virtual-guest on bare metal will hurt performance.
Choose the right profile for your environment
Use balanced when you are running a desktop or laptop and want a mix of responsiveness and power efficiency. Use throughput-performance when you are running a database or web server and need maximum sustained I/O and CPU throughput. Use latency-performance when you are doing real-time audio, video editing, or running latency-sensitive simulations. Use virtual-guest when Fedora is running inside a VM and you want the guest to optimize for virtualized hardware. Use virtual-host when the machine is a hypervisor hosting other VMs and needs to optimize for virtualization overhead. Use network-latency when you are running high-frequency trading or low-latency network services. Use network-throughput when you are moving large amounts of data over the network and need maximum bandwidth. Stay on balanced if you are unsure. It is the safest default and rarely causes issues.