Date: Tue, 21 Jan 2020 20:59:00 +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-pPa78LMTs1@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 #2 from Conrad Meyer <cem@freebsd.org> --- Can both of you try: Adding 'debug.hwpstate_verbose=3D"1"' in /boot/loader.conf and checking dme= sg 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=3Dfoo' 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 =E2=80=94 it's BIOS dat= a 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 documen= ted on Zen PPR as: *********************** "Writes to this field cause the core to change to the indicated __non-boost= ed__ P-state number=E2=80=A6" (emphasis added) *********************** So, e.g., writing P0 (unlimited) still disables boost, I guess. Interestingly, the documentation on the boost enable/disable bit (HWCR::Cpb= Dis) 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) wh= en "P0" is selected. Or we could synthesize an extra P-state, e.g., "3701" wh= ich when selected sets P0 and also boost. IMO, that's more effort than it's wo= rth because manual P-state setting is silly on these CPUs. Here's a test you could do to confirm. Set dev.cpu.0.freq=3D3700, or whate= ver 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&=3D~0x02000000' /dev/cpuctl0" and see if it rest= ores 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.) --=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-pPa78LMTs1>