> 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.
