On Thu, Jan 29, 2026, at 4:09 PM, Olivier Certner wrote:
> > On Intel, and now on AMD, it seems that CPPC is far worse than powerd (*).
> 
> That must depend on workloads and objectives then, since I've had the 
> opposite experience on laptops in terms of latency.
> 
> > (...) And high settings use more power.
> 
> But providing better performance, or not?

The same, not better.  But statically setting cppc tunables so the performance 
is as good as powerd's performance means far more power is consumed when we are 
close to idle.

> > So the ability to let software control frequency is something that I don't 
> > want to loose.
> 
> I certainly don't have plans to remove that.  When talking about recommending 
> CPPC, I was thinking about the default value we wanted to have for the new 
> 'machdep.hwpstate_amd_cppc_enable' tunable, but not about removing it.  IMO, 
> this tunable is here to stay (it might just change form at some point).
> 
> I also encourage you to give a shot at the patch in PR 292615, in order to 
> see how the new knobs (min & max performance, desired performance) can affect 
> your observations, even if after what you reported that may look unlikely.
> 
> For the future, we should probably eye at teaching powerd(8) about working 
> with CPPC, so that instead of trying to set frequencies directly (which 
> cannot really work with and basically defeats the point of CPPC) it would 
> instead tune the desired performance value (and possibly the min and max ones 
> as well).  Perhaps with that combination we could get the best of both worlds 
> (software + hardware tuning), at least for some workloads.

In reading some of the docs for this, I got the impression that CPPC can 
basically be 2 things

1) A hardware controlled power governor, like our powerd or Linux's frequency 
governors.
2) A way to expose far more control over CPU frequency than pstates give us 
(especially on AMD, where pstates generally only give 3 freqs)

I'm not at all interested in (1), as I think powerd or something like it does a 
far better job at trading off power and performance then CPPC on both Xeon and 
EPYC.   However, I think (2) would let powerd do a far better job and I'd be 
very interested in getting CPPC to optionally expose more frequencies and not 
do any automatic governing.

Drew

Reply via email to