> Date: Fri, 20 Nov 2020 16:54:59 +0100 > From: Otto Moerbeek <[email protected]> > > On Fri, Nov 20, 2020 at 09:48:47AM -0500, Bryan Steele wrote: > > > On Fri, Nov 20, 2020 at 03:08:42PM +0100, Mark Kettenis wrote: > > > > Date: Fri, 20 Nov 2020 07:41:20 -0500 > > > > From: Bryan Steele <[email protected]> > > > > > > > > On Fri, Nov 20, 2020 at 09:26:08AM +0100, Otto Moerbeek wrote: > > > > > Hi, > > > > > > > > > > I got a new Ryzen machine, dmesg below. What I'm observing might be a > > > > > issue with hw.setperf. > > > > > > > > > > On startsup it shows: > > > > > > > > > > hw.cpuspeed=3800 > > > > > hw.setperf=100 > > > > > > > > > > If I lower hw.setperf to zero, the new state is reflect immediately in > > > > > hw.cpuspeed: > > > > > > > > > > hw.cpuspeed=2200 > > > > > hw.setperf=0 > > > > > > > > > > And also sha256 -t becomes slower as expected. > > > > > > > > > > But If I raise hw.setperf to 100 I'm seeing: > > > > > > > > > > hw.cpuspeed=2200 > > > > > hw.setperf=100 > > > > > > > > > > and sha256 -t is still slow. Only after some time passes (lets say a > > > > > couple of tens of seconds) it does show: > > > > > > > > > > hw.cpuspeed=3800 > > > > > hw.setperf=100 > > > > > > > > > > and sha256 -t is fast again. > > > > > > > > > > This behaviour is different from my old machine, where setting > > > > > hs.setperf was reflected in hs.cpuspeed immediately both ways > > > > > > > > > > Any clue? > > > > > > > > > > -Otto > > > > > > > > Hey Otto, > > > > > > > > Nice machine! :-) > > > > > > > > I've seen this "sticking" issue before (as have others), but haven't > > > > been able to narrow it down unfortunately. I'm not sure if it's a > > > > bug in the k1x-pstate.c code I wrote, it's some undocumented new > > > > behaviour on newer Ryzen CPUs, or if a MI setperf change happened > > > > at some point that's unhandled.. > > > > > > > > At least on a desktop I'd suggest to leaved apmd(8) and not do any > > > > manual hw.setperf tweaking, you should have adequate cooling and the > > > > BIOS will automatically adjust the CPU fan to keep it so. I believe > > > > it will also allow it to more quickly move into CPB boost frequencies > > > > if left at P-state L0 (but don't quote me on that). > > > > > > I would expect this machine to use the acpucpu(4) setperf > > > implementation. Figuring out if that is indeed the case would > > > probably be step 1 in debugging this. > > > > I didn't realize there was a setperf implementation in acpicpu(4), > > k1x-pstate depends on acpicpu(4) to to gather PSS information, but > > otherwise writes the MSRs out itself rather than calling any ACPI > > methods. > > > > In identifycpu() we're just matching on family, e.g: > > if (ci->ci_family >= 0x10) > > setperf_setup = k1x_init; > > > > The Intel SpeedStep case is below and matches based on a CPUID flag, > > so I don't see when the acpucpu implementation would ever be chosen > > at on either.. > > > > -Bryan. > > > > It's k1x_init being called to print the speeds.
Ok, well, that may be wrong. I'll take a look at what happens on my x395.
