hwpstate_amd(4): CPPC: Switch the default to maximum performance

[olce]

Summary

Set controls to maximum performance to avoid regressions now that CPPC
is activated by default and to match what the P-state support does.

Sponsored by: The FreeBSD Foundation

[olce]

Let me explain the context for this, so that we can discuss if this is the best solution or if we should find something else, both short term and longer term.

hwpstate_amd(4) is compiled-in in GENERIC by default (as part of cpufreq). Contrary to hwpstate_intel(4), this driver not only contains the new CPPC support, it also supports the regular, fixed P-states.

So far, we have chosen to enable CPPC support by default when supported by the processor. As PR 292615 has shown, this can cause a performance regression (cracauer@'s case), and does make powerd(8) ineffective (cy@'s case; apparently he found acceptable settings of CPPC knobs for his use case, with possibly better hardware reactivity than powerd(8)'s).

To add to the equation, once CPPC support is enabled, it cannot be disabled (except by a processor reset).

For the short-term:

• Either we keep CPPC support enabled by default, and then, in order to avoid performance regressions but also to be consistent with all other cpufreq drivers except hwpstate_intel(4), I push this revision, that sets the knobs by default to maximum performance.
• Or we disable CPPC support by default, if we find making powerd(8) stop working on processors with CPPC support out-of-the-box is not acceptable, and then I may or may not push this change (I'd be inclined to push it anyway). Note that hwpstate_intel(4) is enabled by default on supported processors, making powerd(8) useless on these, so there is a precedent in favor of enabling CPPC by default.

Longer term, widening the perspective:

• We need a manual page.
• We should change the default tuning for hwpstate_intel(4) accordingly (i.e., start with maximum performance), even if this is a default behavior change.
• hwpstate_intel(4) should be modified to match hwpstate_amd(4), with EPP values between 0 and 255 (even if that breaks compatibility; today the scale is 0 to 100), and addition of the other performance knobs (and debugging output; basically all my recent work on hwpstate_amd(4)).
• Teach powerd(8) about CPPC controls and how to use them instead of trying to set frequencies.
• Maybe split hwpstate_amd(4) in 2 drivers (one for regular P-state, the other for CPPC), but then which one attaches should be handled in some way, probably via the default driver machinery priorities (instead of the hack hwpstate_intel(4) uses vis-à-vis est(4)). Doing this, among others, would allow to disable CPPC through the usual hint mechanism instead of the ad-hoc knob machdep.hwpstate_amd_cppc_enable.

[olce]

Adding a task to the list above:

• On resume, we need to re-program the CPPC_REQUEST MSR, else current settings do not apply anymore.

(Was prompted by a discussion with Robert Augustinus on hackers. My response mail was partially wrong about suspend/resume: We indeed do not need to do anything on suspend, and certainly not try to deactivate CPPC, but we need to enable it back on resume.)

[aokblast]

sys/x86/cpufreq/hwpstate_amd.c

838

This is not correct. Desired perf should be 0 to enable autonomous mode.

[olce]

sys/x86/cpufreq/hwpstate_amd.c

838

The purpose of this change is to enable maximum performance *instead* of enabling autonomous mode to avoid regressions in some cases (see PR 292615).

Now, I'm open to discussion to how we could tweak the defaults differently depending on other factors.

Once, you suggested to enable CPPC only if ACPI's _CPC object is present. While I think this is a too extreme measure (experiments in PR 292615 on one of the machines shows that AMD CPPC can be useful even if _CPC is absent, EPP has no effect and there's no autonomous mode at all), we could have the variant of deciding to enable autonomous mode instead of maximum performance when _CPC is present (and perhaps on EPP's presence too). But the more I think about it, the more I found adding platform-dependent special cases confusing for end users, because they often do not know (and arguably, should not need to know, as much as possible) the specific details of their platform.

So, I think a likely better direction is to try to determine if the machine is a laptop or a desktop (we could use ACPI for that, specifically the Preferred_PM_Profile field of the FADT table, maybe falling back on other sources, perhaps SMBIOS or UEFI (for this last one, I'm unaware of standard means to determine if the running platform is a laptop or not)).