On my system, powerd functions just fine. Powerdxx too. Maybe it's just my system though. I feel like powerd and powerdxx really does the job well.
T, 10. veebruar 2026, 19:45 Drew Gallatin <[email protected]> kirjutas: > > > 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 >
