Architecture-Aware
CPU Performance
for Linux

The core insight is that modern CPUs increasingly hide low-level control behind firmware, CPPC, HWP, SCMI, ACPI, BMC/EC, and platform controllers. Intel's intel_pstate, AMD's amd-pstate, and ARM's SCMI framework each expose fine-grained performance knobs — but through completely different interfaces that require completely different knowledge to navigate safely.

A unified policy layer that understands all three architectures, detects what each platform actually supports, and applies the right controls through the right interfaces doesn't exist yet. That's CPUOpt-Kernel.

The Linux kernel's CPUFreq subsystem has evolved enormously in the past three years. Understanding what exists — and what each layer owns — is prerequisite to building anything safe.

Intel's HWP (Hardware P-States) — available since Skylake — fundamentally changes who drives frequency decisions. When HWP is active, the CPU sets its own P-states autonomously; intel_pstate gives hints via the Energy Performance Preference (EPP) register, not commands. Writing 0x00 to EPP says "bias toward performance"; writing 0x80 says "balance"; 0xFF says "power efficiency." The kernel sets EPP to zero — full performance focus — when the performance governor is active.

AMD's amd-pstate, based on ACPI CPPC (Collaborative Processor Performance Control), provides far more granular control than the legacy acpi-cpufreq driver which exposed only three P-state steps. In active (EPP) mode, the AMD firmware autonomously adjusts frequency given hints; in guided mode, the driver sets min/max bounds and firmware picks within that range. As of Linux 6.14, the AMD P-State driver saw the most changes in the PM subsystem — Ryzen now defaults to balance_performance EPP while EPYC server chips default to full performance.

ARM platforms present the most fragmented picture: Ampere Altra, Qualcomm Oryon, NVIDIA Grace, Neoverse N2, Apple M-series (Linux via Asahi), Rockchip, and MediaTek all expose completely different performance control surfaces. The common thread is SCMI — the System Control and Management Interface — which lets the OS request performance levels through firmware rather than touching registers directly.

CPUOpt-Kernel is structured as a layered kernel driver framework, not a userspace daemon. Userspace daemons get clobbered by other tools; a kernel module can coordinate properly with existing PM drivers and intercept the right hooks.

The sysfs interface is minimal and intentional:

The userspace control tool is intentionally simple. The kernel module does the intelligence; cpuoptctl is just a thin sysfs wrapper:

Each architecture requires a fundamentally different approach to performance control. The vendor backend model lets CPUOpt-Kernel implement each correctly without compromise.

Generic governors ("performance," "powersave") are too coarse. The same system running LLVM compilation and AI inference needs different knob positions: compilation benefits from all-core sustained clocks and efficient deep-sleep when idle; inference needs no C-state latency penalties and maximum uncore bandwidth at all times.

CPUOpt-Kernel's safe_mode flag (default: enabled) restricts all operations to level ①–②. Level ③ and ④ require explicit opt-in per platform with capability verification. This is not timidity — it's the only way to ship something that doesn't brick systems.

The Intel Software Developer Manual Volume 4 (MSR reference), AMD Processor Programming Reference for each family, and ARM SCMI/PSCI specifications are the authoritative sources. No register write happens in CPUOpt-Kernel without a line citation in one of these documents.

Every existing CPU tuning tool is open-loop: set a governor, walk away. CPUOpt-Kernel's differentiating capability is its telemetry-driven feedback loop. The policy engine continuously observes what the hardware is actually doing and adapts — before thermal or power-limit throttling degrades your workload.

The feedback loop runs at a configurable interval (default: 250ms). When PL2 power-limit throttling is detected, the loop backs the EPP hint down slightly before the firmware's own thermal management engages — resulting in smoother sustained performance rather than the sawtooth frequency profile that characterizes unmanaged boost behavior.

This is the difference between a system that runs at 4.8 GHz for 10 seconds then drops to 3.2 GHz for 2 seconds (unmanaged) and one that sustains 4.3 GHz continuously (managed). For AI inference, that second behavior produces lower median and p99 token latency even though the peak frequency is lower.