cpufreq_driver_adjust_perf(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ‘‘ cpufreq_driver_adjust_perf(9) β€” Kernel API Manual, bestie edition πŸŽ€

okay so you're in the kernel API manual (cpufreq_driver_adjust_perf(9)) and you found the function that adjusts CPU performance level in one go. one go!! no half measures. let's get into it ✨


🌸 SYNOPSIS 🌸

void cpufreq_driver_adjust_perf (struct cpufreq_policy *policy ,
unsigned long min_perf , unsigned long target_perf , unsigned long
max_perf , unsigned long capacity );

like, five args, one call, no sleeping, we move πŸ’…


πŸ¦‹ ARGUMENTS πŸ¦‹

  • policy β€” the cpufreq policy object of the target CPU. it's giving "who am i doing this for" energy.
  • min_perf β€” the minimum (required) performance level, in units of capacity. the floor, the bare minimum, the "at least this much" πŸ₯Ί
  • target_perf β€” the target (desired) performance level, in units of capacity. the dream. the goal. the main character number.
  • max_perf β€” the maximum (allowed) performance level, in units of capacity. the ceiling, the limit, the "bestie no further" πŸ›‘
  • capacity β€” the capacity of the target CPU. iykyk.

πŸ’– DESCRIPTION πŸ’–

So basically: this carries out a fast performance level adjustment for the CPU represented by policy without sleeping. no naps. none. it's awake and it's working πŸ”₯

The driver's ->adjust_perf callback invoked by this function must be suitable for calling from within RCU-sched read-side critical sections β€” and it's expected to program the processor to select suitable performance levels between min_perf and max_perf inclusive, and preferably close to target_perf going forward for the CPU represented by policy. so: stay in the range, aim for the vibe, look cute doing it 🌈

⚠️ Do NOT call this function if policy->fast_switch_enabled is unset. literally don't. that's the vibe check and you failed it πŸ’€

Governors calling this function must guarantee two things, and these are non-negotiable fr fr:

  1. it will never be invoked twice in parallel for the same CPU, and
  2. it will never be called in parallel with either ->target or ->target_index or ->fast_switch for the same CPU.

no overlapping calls, no crossover episodes, no parallel chaos. periodt. πŸ‘‘


πŸ” SEE ALSO πŸ”

Kernel file ./drivers/cpufreq/cpufreq.c β€” and the whole friend group, no one left out:


anyway that's the whole page, hope it ate πŸ“ this one lives in ./drivers/cpufreq, dated October 2026, and it goes by cpufreq_driver_adjust_perf(9) β€” mwah, bye bestie! πŸ’œπŸ§šβœ¨

πŸ“¦ where this page comes from