From owner-freebsd-bugs@freebsd.org Tue Jan 21 20:59:01 2020 Return-Path: Delivered-To: freebsd-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8340F222862 for ; Tue, 21 Jan 2020 20:59:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 482LVs2ymJz42nL for ; Tue, 21 Jan 2020 20:59:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 64009222861; Tue, 21 Jan 2020 20:59:01 +0000 (UTC) Delivered-To: bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 63C4922285F for ; Tue, 21 Jan 2020 20:59:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 482LVs22prz42nK for ; Tue, 21 Jan 2020 20:59:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 280CB1A947 for ; Tue, 21 Jan 2020 20:59:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 00LKx1QT005533 for ; Tue, 21 Jan 2020 20:59:01 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 00LKx1Jw005532 for bugs@FreeBSD.org; Tue, 21 Jan 2020 20:59:01 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f 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 Date: Tue, 21 Jan 2020 20:59:00 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: cem@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 20:59:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D234733 --- Comment #2 from Conrad Meyer --- 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.=