Linux CPU Undervolting with intel-undervolt
Linux handles CPU undervolting by providing low-level access to the
processor's Model-Specific Registers (MSRs) through specialized kernel
modules, bypassing the need for heavy graphical utilities like Windows'
ThrottleStop. Instead of running a continuous background GUI
application, Linux relies on lightweight command-line daemons such as
intel-undervolt to apply voltage offsets to CPU cores,
cache, and integrated graphics. This article explains the underlying
mechanisms Linux uses to interface with hardware registers, how
intel-undervolt replaces ThrottleStop functionality, and
how power limits are enforced across system state changes.
Kernel-Level MSR Access in Linux
Unlike modern Windows environments where software interfaces with
proprietary manufacturer drivers to alter voltages, Linux natively
manages hardware-level processor states via the msr kernel
module. When loaded, this module creates character devices at
/dev/cpu/[core_id]/msr.
CPU undervolting relies on writing specific bitmasks to Intel's
voltage control register (MSR 0x150). Because direct access
to MSRs can expose system memory and introduce hardware instability,
Linux strictly limits read and write operations to processes with root
privileges or the CAP_SYS_RAWIO capability. Tools interact
with these nodes via standard POSIX system calls (open,
pread, pwrite), delivering voltage
instructions directly to the CPU microcode.
How
intel-undervolt Replaces ThrottleStop
ThrottleStop is widely used on Windows to control CPU voltages, power
limits (PL1/PL2), and thermal trip points through an interactive
graphical interface. On Linux, intel-undervolt acts as a
headless, resource-efficient alternative written in C.
intel-undervolt parses a human-readable configuration
file located at /etc/intel-undervolt.conf. In this file,
users define negative millivolt (mV) offsets for five distinct voltage
planes:
- CPU Core: The main computing execution units.
- CPU Cache: The L3 uncore and cache bus, which typically requires a matching offset with the core for stability.
- Intel GPU: The processor's integrated graphics.
- System Agent: Memory controller and peripheral buses.
- Analog I/O: Chipset and secondary input/output paths.
Upon execution, the utility calculates the appropriate hexadecimal
values and writes them to MSR 0x150, instantaneously
lowering the voltage profile configured by the motherboard's Dynamic
Voltage and Frequency Scaling (DVFS) tables.
Handling Power Limits via Intel RAPL
Beyond pure voltage control, ThrottleStop manages processor power
limits to prevent thermal throttling. Linux achieves this through the
Running Average Power Limit (RAPL) interface, exposed by the kernel
under /sys/class/powercap/intel-rapl/.
intel-undervolt reads and modifies these powercap sysfs
nodes directly. Users can configure sustained power limits (PL1), burst
limits (PL2), and time windows. When configured,
intel-undervolt writes to the relevant RAPL MSRs
(MSR_PKG_POWER_LIMIT), allowing the Linux kernel's thermal
and power governors to dynamically manage clock speeds within
user-defined wattage envelopes.
Persistence Across Power States
ThrottleStop typically runs continuously in the Windows system tray to re-apply settings after waking from sleep. In Linux, continuous execution is unnecessary because register values only need to be written when the processor resets or changes power states.
Linux manages persistence through systemd:
- Boot Execution: A
systemdservice (intel-undervolt.service) executes once during the multi-user boot target, writing configured offsets to the hardware registers. - Suspend and Resume: Modern Intel CPUs reset their
internal registers to default voltages when waking from deep sleep
states (S3/S0ix). Linux handles this through systemd sleep hooks
(
systemd-suspend.serviceandsystemd-hibernate.service), triggeringintel-undervolt applyimmediately upon system wake. - Periodic Re-application: An optional
intel-undervolt-loop.servicecan run as a low-overhead timer daemon to ensure voltages remain locked even if system firmware or aggressive thermal daemons (likethermald) attempt to override them during runtime.