From nobody Mon May 25 11:47:45 2026 X-Original-To: freebsd-current@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 4gPDf31fdfz6fFxH for ; Mon, 25 May 2026 11:47:55 +0000 (UTC) (envelope-from olce@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R12" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4gPDf30zdGz3Ksg; Mon, 25 May 2026 11:47:55 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1779709675; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1bQRkGeN/JvMM6VHDZtsrn/sPXZwjWSwtBcGdOzmJcE=; b=DZZRZMSRHYtERdj9/alvb7qV51JbHYdpMdKiNacwThLsyqQbPg6UYQsu/FSOdWSF3IhkQ5 mKN6wV4+Zom86liFIvfMnVXyGhEvmUlD8yKHPi81g1RLvvGTtRmDPslumozuv6NPTXYI4j H+IUk68OvcS+9xO91NlsaPdO0uPf7hrJqXayORN/y+K3SXPQEbODLWOV99DmN9VJSRb3Cf Lw+AZNwlAax5wL7HmGCDmks4TFjNqwY23HqD97QTeB9rA3TEKuBKNv51mbYfwSWuHDk7yr qJS1YiXuBN2fHWC7jur3xIfup3+K6XYmoy76zMbyVqsKo8FHG+Ur96KaESGcaQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1779709675; a=rsa-sha256; cv=none; b=W53su7KrUeh2YOkMlp1LMHU0oGQniQp17XtHi2ljO49klC+ljTol+Mw3fan48HuK3RMkfr 3fFbU5kLUUTqCOMfJ6nSaV5ktDr2eXONK5Of594498HuUWu9lfJ3BVMIP97CK7iZUOtbP/ soskGBu19eO+659+WdOmdGUNNj1kJfX7EdGPugvk3RmIXNj44BQrUEHAgU7YxMaxJlmHNX lwkpzKzkxMgJrX9gKXLQuu8xWdDzRttpnyI4MsvecO1Vy+V2gftmwR2i+t1nH6t1LOPgar TRMYD2hQ3+IUJ4h05ulVBOOudqaKojyGp+2opa6CUGr6/KU3BtbCBts5aLMQqg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1779709675; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1bQRkGeN/JvMM6VHDZtsrn/sPXZwjWSwtBcGdOzmJcE=; b=WUjp+HdVy6U0QI/dyMyoVRnIWfQTueQsgjSk2f8Y/hX92SmJi5DAkRvz59hFRry+AKgO5A cbamBIFn32IiEl9WcOe8ENSzPynCNygeWcIWQMlXf0HRTB4NPiMefuab21uvlShtAMwCgs z8TlA/Vs0H981eChrL5QMyfxRQiGlPUMp1T/SbYy6eH80uCJqAyuBEQjpjCGe6yF959WJ5 wE4c8miqet59U47shdNklJ3IKrZyYlDoT4MB9elCBZLPh0fWTDk+q6xYZL2qInQd8C4fjS e4Fo/9Lxb9bYRdKHvLM67wVKay+0oG6Kl8eXqhxhK9MOVAjcKq5svRQ0soLDMw== Received: from ravel.localnet (lfbn-nic-1-328-19.w90-116.abo.wanadoo.fr [90.116.162.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: olce/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4gPDf231CHzkXc; Mon, 25 May 2026 11:47:54 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Chris Torek , Adrian Chadd Cc: freebsd-current , ShengYi Hung Subject: Re: AMD, CPPC, etc Date: Mon, 25 May 2026 13:47:45 +0200 Message-ID: <1978836.vR5SVPPSqJ@ravel> In-Reply-To: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart24730495.gYbqZ1YImA"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart24730495.gYbqZ1YImA Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8"; protected-headers="v1" From: Olivier Certner Subject: Re: AMD, CPPC, etc Date: Mon, 25 May 2026 13:47:45 +0200 Message-ID: <1978836.vR5SVPPSqJ@ravel> MIME-Version: 1.0 Hi, > > Commit 80d32a6b1d73 (hwpstate_amd(4): CPPC: Switch the default to > > maximum performance) cranks my 7950-based system from its 90-to-100 > > watt idle draw up to 150+ watts. If I set > > dev.hwpstate_amd.0.desired_performance=0, it goes back down, so this > > isn't too big a deal, but I see that powerd has no idea about using > > the CPPC control knobs. powerd(8) still does not know about these CPPC controls. We have plans to change it. Actually, we wanted to produce a PoC at AsiaBSDCan two months ago, but this was thwarted by illness there... See pointers below. I won't have time to devote to this until the hackathon after BSDCan. I don't know about ShengYi, it seems he's busy with other topics. > Would you please file a PR about powerd and CPPC control knobs? That would be a good idea, to better keep track of past discussion and what's happening. Some pointers to previous messages/discussions: - https://lists.freebsd.org/archives/cu/2026-February/009918.html - The end of https://lists.freebsd.org/archives/freebsd-hackers/2026-February/005774.html - https://reviews.freebsd.org/D55253 > I'd much prefer that powerd bump the CPU frequency up to the highest (eg what it does on ARM, > powerpc64 p8/p9 boxes) versus expecting the kernel to configure that > at boot. The commit mentioned above ("hwpstate_amd(4): CPPC: Switch the default to maximum performance") was done to fix the regression caused by enabling CPPC by default in hwpstate_amd(4) (which perhaps we did prematurely). hwpstate_amd(4) has been our driver for regular P-states from the start (before growing the CPPC support), and by default it selects the state with maximum frequency, which we have wanted to reproduce. This is different from what the hwpstate_intel(4) driver, which only supports CPPC for Intel processors (and not P states), does, which is to keep Intel's initialization value for EPP (as mentioned just above), i.e., some balanced setting. I have not checked whether Intel implements CPPC on its desktop processors. Going further, I have been considering changing hwpstate_amd(4)'s defaults (maximum performance => some balanced setting (which itself is not that well-defined for CPPC both in theory and apparently in practice on AMD processors)) if running on a laptop (see last comment of D55253 mentioned above). The CPU model above (7950) is a desktop one, and not setting such a CPU to its maximum performance by default a priori appears to me as a much more controversial change. I guess people do not run powerd(8) on desktop machines (and maybe a number of them do not run powerd(8) either on not too old Intel laptops due to hwpstate_intel(4)). We might consider switching to a model where powerd(8) is always run by default, but that probably requires significant work on powerd(8) to make it much smarter. On a related note, going forward, we might want to move part of powerd(8)'s logic into the kernel. How does CPU frequency selection and default values work on powerpc64/ARM? Regards. -- Olivier Certner --nextPart24730495.gYbqZ1YImA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmoUNuEACgkQjKEwQJce JiezYA/9E53b7EaDzJZ29eexUB3NGfrF8DS7/2/HphlERnxo+/9/SdUYmB2OeKGB RJhcii6o9NmaiD8bUukg8g6iz7z3bo1qOn36ckVtjCvWxOAYaMfdA8xUJwBbR2eX fujmog55KfS5Z5Qt5pfMJNkq7RlpxR26u/fh2uigu8pghuG39lL5feQT6zMjKKDr WMDlmVRWe2Plu6C4rHoRUwSTns9l/GsfJks2QzilofoIqIXoTXQWi7cU+G9hHKOu gFNSkKkaPwlfLqrb0OP4NULlEvkeup+Cfm4Kuby7j3+p7yabr8mlEXWJwf12mM+g WyhFmu8YaqTmlxCfdCGjHqGrz8K+ZZSOUlz6+nz87WPvDQwNztfbjrPUFiWES6Ge HyxZS6Vp6eiVFOj7keRyQJ0TG2XMFLtlyDWSabs0u81WWGobWG9q0fb27lI/EaaM dRYLIKszSQYjkS8dTrr5RK7Rhhq2QWRf9niMAiB8JzxMhm/LWL/3bJaQKsrYKIHs 93ACYUnrylXgW0pPCoVpu2dTDDm3b2rkYHwkjwTLIIHUpapxqhKCqaZmTYu0kb33 Rfis5SaMjZFdiTQ30iqXFw/u3qwmPrEI/1RrMP1Ri35bTxbj2I/4GjI1PbVz7TBO OJFCCSxxoh/1Uxf54X8iqZXhVybK9vjmnsEiBZF9kkXkqXSYbYE= =1IMP -----END PGP SIGNATURE----- --nextPart24730495.gYbqZ1YImA--