From nobody Mon May 15 21:16:21 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QKscc401Dz4B5wD for ; Mon, 15 May 2023 21:16:32 +0000 (UTC) (envelope-from jo@bruelltuete.com) Received: from email.jo-t.de (seppel.jo-t.de [45.132.244.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4QKscZ4XXZz4PcS for ; Mon, 15 May 2023 21:16:30 +0000 (UTC) (envelope-from jo@bruelltuete.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bruelltuete.com header.s=bruelltuete18a header.b=TxYZIb5h; spf=pass (mx1.freebsd.org: domain of jo@bruelltuete.com designates 45.132.244.126 as permitted sender) smtp.mailfrom=jo@bruelltuete.com; dmarc=pass (policy=none) header.from=bruelltuete.com DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bruelltuete.com; s=bruelltuete18a; t=1684185384; bh=1NUu+6Mxuvfc8E01Jro4y7FNV4Lv/IMWhTkJBX3umdc=; h=Message-ID:Date:MIME-Version:To:From:Subject:From; b=TxYZIb5hIxB/rnXVtrxgrBWYwav1OD7J+mdqsx0V0/lTCJGEFaBUAkbrweJ7vhDg0 QK52GwnIVmusQpWVoJq0K7FhJVVooq76Nsvw0EAumrCEzq1jPgZjdGLN0Kcn6z35pR t2yXwkVf8p0xVZ6c+JTIGdk6KLkRKds4tDT2HPVHjl99uZW0detJfDCXNBM71oL+Zd Wph+TXQgP7YUwPN0CDx5opTcZbXEvFu8lgrQSlHt3Te13fu9US4USptJYGQbgbt6Ez p+YZnnhV0QynP0pzRIRoCsGbrBb44usqlnJDKamuOxObaEVonJBT2GsjWHSGxMPBZf qMJwU69ZMtN5w== Message-ID: <576641a3-8b9c-fedb-67a6-a5c61a52f654@bruelltuete.com> Date: Mon, 15 May 2023 22:16:21 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-Mozilla-News-Host: news://news.gmane.io:119 Content-Language: en-GB To: FreeBSD Hackers From: Johannes Totz Subject: cpufreq & hwpstate_amd & Zen 2 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[bruelltuete.com,none]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[bruelltuete.com:s=bruelltuete18a]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; ASN(0.00)[asn:197540, ipnet:45.132.244.0/22, country:DE]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[bruelltuete.com:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4QKscZ4XXZz4PcS X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Hi all, I'm poking cpufreq's hwpstate_amd to see what I can tune re performance vs power vs heat trade-off. I'm struggling with the P-state behaviour though. The code looks really straight-forward: https://github.com/freebsd/freebsd-src/blob/main/sys/x86/cpufreq/hwpstate_amd.c#L172 But enabling hwpstate_verify, it looks like P-state transitions never go as requested. For this, I'm not running powerd. In addition to the existing verify code, I've sprinkled in a few more printfs. PStateCurLim (aka MSR_AMD_10H_11H_LIMIT = 0x20) and PStateDef (aka MSR_AMD_10H_11H_CONFIG = eg 0x8000000049120890) look all reasonable. $ sysctl dev.cpu.0 dev.cpu.0.freq_levels: 3600/3960 2800/2800 2200/1980 dev.cpu.0.freq: 2800 $ sysctl dev.cpu.0.freq=3600 dev.cpu.0.freq: 2800 -> 3600 $ cat /var/log/messages [...extra printf debugging...] kernel: hwpstate0: setting P0-state on cpu0 kernel: hwpstate0: setting P1(2) -> P0 on cpu1 [...same for all the other cpus...] kernel: hwpstate0: setting P1(2) -> P0 on cpu15 This shows that cpufreq thought we were at P1 and wanted to transition to P0. But actually, the CPU was in P2 (the 2 in brackets). We want to go from P0 to P2... $ sysctl dev.cpu.0.freq=2200 dev.cpu.0.freq: 3600 -> 2200 $ cat /var/log/messages kernel: hwpstate0: setting P2-state on cpu0 kernel: hwpstate0: setting P0(1) -> P2 on cpu1 ...but CPU was in P1 at that time. Wanting to go from P2 back to P1... $ sysctl dev.cpu.0.freq=2800 dev.cpu.0.freq: 2200 -> 2800 $ cat /var/log/messages kernel: hwpstate0: setting P1-state on cpu0 kernel: hwpstate0: setting P2(2) -> P1 on cpu1 ...shows that this time the CPU really was in P2 (yeay). But it did not transition to P1, it stayed in P2 (not shown in the log). So question is: what else could be interfering with P-state? thanks, Johannes