Date: Wed, 22 Jan 2020 18:02:05 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 234733] Setting CPU frequency with sysctl dev.cpu.0.fr slows a Ryzen 2700X down Message-ID: <bug-234733-227-kIsi5epn9L@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-234733-227@https.bugs.freebsd.org/bugzilla/> References: <bug-234733-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D234733 --- Comment #4 from sigsys@gmail.com --- Created attachment 210970 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D210970&action= =3Dedit acpidump -dt (In reply to Conrad Meyer from comment #3) Alright I tested a bunch of things based on that. It doesn't seem to be related to CPB in this case. The 0x02000000 bit never gets set (it always shows "MSR 0xc0010015: 0x00000000 0x09000011"). I trie= d to toggle it on and off again anyway in case it would reset something but it doesn't seem like it does. The CPU just seems to get stuck at the lowest frequency it has been set to. I tested by timing this: dd if=3D/dev/zero bs=3D32k count=3D20000 | cpuset -l 0 time sha1 And by setting the frequency to 3200 (maximum), 2800 and 1550: 3200: 1.34 real 1.15 user 0.17 sys 2800: 1.78 real 1.47 user 0.30 sys 1550: 3.18 real 2.78 user 0.39 sys After lowering the frequency to a given value, there's no way to get the performance back (but it lets you set the frequency higher with sysctl with= out any apparent errors). With debug.hwpstate_verbose set, there's that during boot: hwpstate0: going to fetch info from acpi_perf hwpstate0: <Cool`n'Quiet 2.0> on cpu0 And a bunch of messages like that when setting the frequency with sysctl: hwpstate0: setting P1-state on cpu0 hwpstate0: setting P1-state on cpu1 hwpstate0: setting P1-state on cpu2 hwpstate0: setting P1-state on cpu3 hwpstate0: setting P1-state on cpu4 hwpstate0: setting P1-state on cpu5 hwpstate0: setting P1-state on cpu6 hwpstate0: setting P1-state on cpu7 hwpstate0: setting P1-state on cpu8 hwpstate0: setting P1-state on cpu9 hwpstate0: setting P1-state on cpu10 hwpstate0: setting P1-state on cpu11 hwpstate0: setting P1-state on cpu12 hwpstate0: setting P1-state on cpu13 hwpstate0: setting P1-state on cpu14 hwpstate0: setting P1-state on cpu15 hwpstate0: setting P2-state on cpu0 hwpstate0: setting P2-state on cpu1 hwpstate0: setting P2-state on cpu2 hwpstate0: setting P2-state on cpu3 hwpstate0: setting P2-state on cpu4 hwpstate0: setting P2-state on cpu5 hwpstate0: setting P2-state on cpu6 hwpstate0: setting P2-state on cpu7 hwpstate0: setting P2-state on cpu8 hwpstate0: setting P2-state on cpu9 hwpstate0: setting P2-state on cpu10 hwpstate0: setting P2-state on cpu11 hwpstate0: setting P2-state on cpu12 hwpstate0: setting P2-state on cpu13 hwpstate0: setting P2-state on cpu14 hwpstate0: setting P2-state on cpu15 Never anything other than P1 and P2. I tested after a reboot and an update to recent 12-STABLE r356965 and the results were all pretty much the same. That's a B450 Pro4 still with BIOS version P3.20. Using non-UEFI boot. An= d I reset it to default settings before the last test. At the time I first reported this it had the latest BIOS version but not anymore. So maybe a B= IOS update would fix it. I'm gonna wait updating it in case more testing could= be helpful. Thanks for looking into it! No other problems apart from that on this computer. And yeah after that I figured that you don't really need to run powerd on these CPUs since they'll throttle themselves automatically anyway and they seem to be doing a good j= ob of it. But if someone does run powerd (or mess with the frequency directly) the permanent and silent slowdown can be a pretty bad surprise. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-234733-227-kIsi5epn9L>