Speaker
Description
ACPI CPPC "autonomous selection" lets the platform pick the CPU performance level itself, within OS-provided min/max bounds and guided by an Energy Performance Preference (EPP) hint. Today cppc_cpufreq exposes this as a per-policy auto_select sysfs toggle layered on top of whatever scaling governor is attached. The result is confusing: once autonomous mode is on, the attached governor (schedutil, ondemand, ...) keeps issuing frequency requests that the hardware ignores, and scaling_governor no longer reflects what actually drives frequency.
cpufreq provides two ways to drive frequency, and CPPC autonomous mode fits neither. Scaling governors use the driver's ->target() callback to apply OS-selected operating points. setpolicy drivers (intel_pstate and amd-pstate "active"/EPP modes) instead let the hardware choose, but CPPC has requirements it does not cover. With setpolicy, the mode is selected globally for all CPUs at the driver level, whereas CPPC's registers are per-CPU and can be controlled per policy. setpolicy also exposes only the performance and powersave policies and provides no ->target() path, while the CPPC spec allows an OS desired_perf hint even when autonomous selection is enabled. So CPPC maps cleanly onto neither model.
This session proposes a third option: modelling autonomous, EPP-biased operation as a per-policy cpufreq governor. Selecting the governor enables autonomous mode and programs the EPP and min/max bounds; switching away restores OS frequency control. EPP is exposed as a per-policy governor tunable, and the autonomous state is reported read-only.
The broader question for the micro-conference is how cpufreq should represent hardware-autonomous selection in general:
- Is a new cpufreq governor the right way to expose autonomous selection at all?
- If a governor is the right model, should it be CPPC-specific or generalized so other drivers can share it?
- How should it relate to the existing setpolicy model used by intel_pstate and amd-pstate?
- Should such a governor also pass utilization-based desired_perf hints to the hardware?
- How should the EPP control be exposed to userspace (naming, accepted values, and consistency with the existing energy_performance_preference interface)?
- What is the migration path away from the current sysfs toggle without breaking existing users?