# tuned watches the machine and keeps a profile applied to it > tuned is a Red Hat daemon for monitoring and adaptive tuning of system devices, which selects or accepts a profile and holds the system in the state that profile describes, with a tuned-adm command line that talks to the daemon over DBus. The project ships hundreds of profiles, a recommendation mechanism that picks a profile from static detection, and a policy file that controls who may change the active profile. **redhat-performance/tuned** — Tuning Profile Delivery Mechanism for Linux - Repository: https://github.com/redhat-performance/tuned - Stars: 1,245 · Forks: 259 - Language: Python - License: GPL-2.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/redhat-performance-tuned ## A daemon that holds a state, not a script that runs once TuneD is described as a daemon for monitoring and adaptive tuning of system devices, and the difference from a boot script is the point. A profile describes a set of parameters the system should have, and the daemon keeps it that way, so the tuning survives a service restart, a driver reload or a configuration change made by somebody else. The word adaptive is doing work in the description too, since the daemon watches the system rather than applying a fixed list once. The project is a Red Hat one, shipped on Fedora, Red Hat Enterprise Linux and their derivatives as the tuned package, optionally with tuned-utils, tuned-utils-systemtap and tuned-profiles-compat. The current code base is 2.0, and the README notes that the older version is on the 1.0 branch for anyone who needs it. The licence is GPL version 2, with a COPYING file, and the DCO file is licensed separately. ## Install, start, enable The three commands are the whole installation story on a Red Hat family system: ```bash # dnf install tuned # systemctl start tuned # systemctl enable tuned ``` The README says you likely should run tuned whenever your machine boots, which is why the enable step is there rather than optional. The package is also built for other systems, since the repository carries a Dockerfile that produces an RPM and then a container image. There is a serious warning before any of this, though, that TuneD is incompatible with cpupower and power-profiles-daemon, and that if you have these services you should uninstall or disable them. That is not a minor caveat, because those daemons manage the same CPU frequency and power policy settings that a tuned profile would, and two agents setting the same knobs is a fight neither wins cleanly. ## tuned-adm talks over DBus, and root is not the only way in The control surface is the tuned-adm utility, which communicates with the daemon over DBus. The permission model is the interesting detail. Any user can list the available profiles and see which one is active, but the active profile can be switched only by the root user or by any user with a physical console allocated on the machine, meaning an X11 session or a physical tty but explicitly not SSH. The rationale is straightforward once stated, since a profile can change CPU governor, disk parameters and power policy, so letting a remote session switch it would be a privilege escalation, while a person at the keyboard is assumed to be the operator. The policy is defined in a file, com.redhat.tuned.policy, in the repository root, which is a polkit policy and therefore the place where that rule is actually enforced rather than merely documented. ## Eight commands cover the whole interface The commands are short and each one does one thing. tuned-adm active shows the current active profile, tuned-adm list lists all available profiles, and tuned-adm profile with a name switches to a different one. tuned-adm off disables all tunings, tuned-adm profile_info shows the description of a given profile or of the current one, and tuned-adm verify checks the current profile against the actual system settings, which is the command that tells you whether the machine really is in the state the profile claims. tuned-adm profile_mode shows the current profile selection mode, and tuned-adm auto_profile enables automatic profile selection. The enabled profile is persisted into /etc/tuned/active_profile, which is read when the daemon starts or is restarted, so the choice survives a reboot even before the daemon has run its detection. ## Automatic selection reads static facts, not a probe The recommendation mechanism is deliberately simple, and the README is clear about the limits. Currently only static detection is implemented, and it decides according to the data in /etc/system-release-cpe and the output of virt-what. The rules for autodetection live in /usr/lib/tuned/recommend.d/50-tuned.conf, and a user can override them by creating a file in /etc/tuned/recommend.d or a file named recommend.conf in /etc/tuned, with the tuned-adm(8) man page holding the details. The default rules recommend profiles targeted to the best performance, or the balanced profile if unsure. The important thing about this design is that the detection does not probe the hardware, it reads a description of the system and a hypervisor identification, which means it is predictable and cheap, and it also means a machine with unusual hardware can be mis-detected in a way nobody notices until a parameter turns out to be wrong. The override files are the escape hatch. ## The repository is a distribution, not a script The top-level entries show what this project is in practice. There is tuned.spec for the RPM build, tuned.service, 00-tuned.conf.systemd and 00_tuned.grub for the systemd unit and the boot command line, 92-tuned.install for the install script, tuned.tmpfiles, dbus.conf for the DBus policy, com.redhat.tuned.policy for the polkit rule, and tuned-main.conf and modules.conf for the configuration. There are profiles/ for the shipped profiles, functions/ for the tunable plugins, modules.conf, libexec/ for the helper programs, systemtap/ for the SystemTap probes behind the optional tuned-utils-systemtap package, and contrib/, experiments/, doc/, man/ and tests/. The GUI is here too, with tuned-gui.py, tuned-gui.glade and a desktop file, and the command line has three implementations, tuned-adm.py, tuned-adm.bash and tuned-adm.zsh, so the tool is usable from a shell that has no Python. The Dockerfile builds an RPM in a CentOS bootc image and then installs it into a final image, with a bootc container lint step that treats warnings as fatal. ## What TuneD is for, and what it is not for The honest scope is a system-level tuning profile, which is a different thing from application tuning. If you want a database server to use a different memory or IO setting, that belongs in the service's own configuration, and TuneD is not the place for it. If you want a class of machine, a database node or a low latency node, to have a set of kernel and hardware parameters that are documented in one file and applied consistently across the fleet, that is what TuneD does well, and the hundreds of shipped profiles are the accumulated knowledge of what a machine type usually needs. The constraints are the ones already mentioned, the conflict with the other power management daemons, and the fact that the profile is a persistent state rather than a per-boot action. The maintenance picture is good, with a stable release v2.28.0 on 2026-08-22, a release candidate v2.28.0-rc.1 before it, v2.27.0 on 2026-02-22, and the last push on 2026-09-10, with the project still adding tuning features and noting that some are described in the manual pages and some are yet undocumented, which is the most useful warning in the README for anybody planning to depend on a specific profile. ## Conclusion tuned is worth knowing about if you run a Linux fleet and want a single documented way to express the settings a machine class needs, because the profile is a file that a human reviews and the daemon keeps it applied rather than leaving it to a boot script. It is the wrong tool if your workload needs a change on every boot rather than a persistent state, since the profile is a configuration the daemon enforces, and the wrong tool if you want per-service tuning, since that is the job of the service's own unit files. Before you install it, read the conflict warning, because tuned is incompatible with cpupower and power-profiles-daemon and having both on a machine fights over the same settings, and check the profile you intend to use rather than assuming the recommended one is right for your hardware. ## FAQ ### How do I install and enable tuned? Install the tuned package with dnf install tuned, start the service with systemctl start tuned and enable it with systemctl enable tuned. The package is available on Fedora, Red Hat Enterprise Linux and their derivatives, optionally with tuned-utils, tuned-utils-systemtap and tuned-profiles-compat. ### Can another user change the active tuned profile? Any user can list the available profiles and see which one is active, but the active profile can be switched only by root or by a user with a physical console allocated on the machine, an X11 session or a physical tty but not SSH. The rule is defined in the com.redhat.tuned.policy file. ### Is tuned compatible with cpupower and power-profiles-daemon? No. The README states that TuneD is incompatible with cpupower and power-profiles-daemon, and that if you have these services you should uninstall or disable them, because they manage the same settings a profile would. ### How does tuned choose a profile automatically? Only static detection is implemented, deciding from the data in /etc/system-release-cpe and the output of virt-what. The rules live in /usr/lib/tuned/recommend.d/50-tuned.conf and can be overridden by a file in /etc/tuned/recommend.d or a recommend.conf in /etc/tuned, with the default recommending the best performance profile or the balanced one if unsure. ## Sources - [Issues](https://github.com/redhat-performance/tuned/issues) - [License: GPL-2.0](https://github.com/redhat-performance/tuned/blob/master/LICENSE) - [README](https://github.com/redhat-performance/tuned/blob/master/README.md) - [redhat-performance/tuned on GitHub](https://github.com/redhat-performance/tuned) - [Releases](https://github.com/redhat-performance/tuned/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/redhat-performance-tuned