[Bug 234733] Setting CPU frequency with sysctl dev.cpu.0.fr slows a Ryzen 2700X down

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733

--- Comment #2 from Conrad Meyer <cem at freebsd.org> ---
Can both of you try:

Adding 'debug.hwpstate_verbose="1"' in /boot/loader.conf and checking dmesg for
boot-time messages about hwpstate?  This can also be sysctl'd at runtime to see
what gets logged when 'sysctl dev.cpu.0.freq=foo' is invoked, for example.

Second, if possible can you share the output of 'acpidump -dt'?  It will be
fairly large and you might have to compress it to attach it to bugzilla.  It
should not contain especially sensitive information — it's BIOS data and code
provided to the operating system to understand system devices.

I'll add: the method hwpstate(4) uses to set the current p-state is documented
on Zen PPR as:

***********************
"Writes to this field cause the core to change to the indicated __non-boosted__
P-state number…" (emphasis added)
***********************

So, e.g., writing P0 (unlimited) still disables boost, I guess.

Interestingly, the documentation on the boost enable/disable bit (HWCR::CpbDis)
also mentions boosted / non-boosted P-states:

"If core performance boost is disabled while a core is in a boosted P-state,
the core automatically transitions to the highest performance non-boosted
P-state."

So... perhaps hwpstate(4) should explicitly check and enable CPB (boost) when
"P0" is selected.  Or we could synthesize an extra P-state, e.g., "3701" which
when selected sets P0 and also boost.  IMO, that's more effort than it's worth
because manual P-state setting is silly on these CPUs.

Here's a test you could do to confirm.  Set dev.cpu.0.freq=3700, or whatever
the maximum is.  Then run (needs root): 'cpucontrol -m 0xc0010015
/dev/cpuctl0'.  This reads the HWCR MSR from CPU0.  The output will look
something like:

MSR 0xc0010015: 0x00000000 0x09000011
If the bit:                0x02000000 is set, it indicates that CPB is
*disabled*.

If that bit is set, you could try:
"cpucontrol -m '0xc0010015&=~0x02000000' /dev/cpuctl0" and see if it restores
boost-level performance.  (I don't know if you would have to clear it on all
CPUs, or if it is globally cleared by the cpu0 command.)

-- 
You are receiving this mail because:
You are the assignee for the bug.