get_next_freq(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

✨ get_next_freq β€” Kernel API Manual ✨

okay bestie, so this one's a little function living in the Kernel API Manual and it's literally the vibe-checker for CPU frequencies πŸ’…

πŸŽ€ NAME πŸŽ€

get_next_freq β€” compute a new frequency for a given cpufreq policy. that's it, that's the whole job 🫢

🌸 SYNOPSIS 🌸

unsigned int get_next_freq (struct sugov_policy *sg_policy , unsigned long util , unsigned long max );

πŸ¦‹ ARGUMENTS πŸ¦‹

  • sg_policy β€” the schedutil policy object we're computing the new frequency for. it's giving "the main character of this whole calculation" πŸ‘‘
  • util β€” the current CPU utilization. yes, right now, in real time, no cap πŸ“ˆ
  • max β€” the CPU capacity. the ceiling, the limit, the "you shall not pass" of this whole thing ⭐

πŸ’– DESCRIPTION πŸ’–

so here's the tea, bestie. if the utilization is frequency-invariant (iykyk), we pick the new frequency so it's proportional to that utilization, like:

next_freq = C * max_freq * util / max

but if it's not frequency-invariant, we approximate the would-be frequency-invariant utilization using util_raw * (curr_freq / max_freq), which lowkey leads us to:

next_freq = C * curr_freq * util_raw / max

and we take C = 1.25 so the frequency tipping point lands right at (util / max) = 0.8. iconic constant, honestly 🌈

anyway, the function returns the lowest driver-supported frequency that is equal to or greater than the raw next_freq (as calculated above), and it's subject to policy min/max and cpufreq driver limitations. so like, no, you can't just manifest any frequency you want, bestie 😭 the hardware has opinions πŸ’€

πŸ”₯ SEE ALSO πŸ”₯


okay that's the whole page, go off πŸ’œ fr fr, this one's from the ./kernel/sched files, October 2026, filed under get_next_freq(9) β€” mwah, slay, periodt πŸŽ€βœ¨πŸ“

πŸ“¦ where this page comes from