From nobody Tue Feb 10 20:21:11 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 4f9XyW6cQtz6RyD2; Tue, 10 Feb 2026 20:21:23 +0000 (UTC) (envelope-from olce@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4f9XyW5rJfz4Q6h; Tue, 10 Feb 2026 20:21:23 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1770754883; 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=U6lmwbIMCaVhEfaxJpMKFLgfK18qmAlLl7Ze+2yR5gg=; b=wx7RPwbPZI/PoND5FsLTxbjgkwGrETd/m7jEZA3XnDjBb1DcGaa8+q3s1KWPD7M6O1SHlJ RgpFKvbn/wdUbTalWlmkCGjaK7CgyXdUc3mxDCVTdNj6r2ZC7KQP354krwOAktDGaQpX4d DllIe7fbPLqFeuk75BAqeggTb1J8Je+p9l9RPp6TxK7KDJijV3d16SgC4bqkFsRLd7ydom 1ZcXQJf1fAiHR8VclbOn2FTxyWd29SLda50ElSay5+hUAhk8d3PHOQLeID3WN8Q5sOgdBb ze9WJW3XOyu5E+/Wf4/KT6aYh5+tPRX6UWDCyGLtvSupFZIITLNQnH1Tc5uFSQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1770754883; a=rsa-sha256; cv=none; b=EogxlrGITTht9nY8uhZscH3/iY8GccyaG2H+qJSBI9X1UClDJ92kGyEV6mJdNgs7UdznW9 4l38b5pfiNhcoDxLX3xn0jwohQmM5pQRtuBbIDcJqDrp7oWHE37w0cXzF7xKjzxKYjeDBu EkbKrUsHlAM/7z6Koy40G4QlnFlyXr0ENoS/kZGxAC6hCWkuad5P72N4865dIX1Cd47KUW g3qUkm1DsL7m7yT+Dml2d8Y+IEwlro0yI0CIdVcOmXIuQwr303sHItA9NfSHHauSSA4vfk lT8MSEb61H3Ccwsj/+dpMlzw6sWSdK+v0CLAydD9aHg5fy7hEgGlv7SZBZTzBw== 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=1770754883; 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=U6lmwbIMCaVhEfaxJpMKFLgfK18qmAlLl7Ze+2yR5gg=; b=ugB6pJxp2BP+d6JFHmTnPbSTetNCzAF4maVa1WOKvpsrcsUN0CCV9kg5/medzdmPN2cub5 FE4FuCM2QsBDudOKd/rzLfmDgYKqQAm3KEXveY/3Idf5s/CwloygUg1woiforVtv2YbP9b PQ9d9cx+PshSjvaPB8+SqLf1q7i8GxeHLImxHSYm4CwpzlRR9L/oHk1j2aYibiHXGwDTZF QO2ovpU4jP2LFiNsQY5014xh0hfs7fI+mkplVDnfZOJf1xJROnpkdJGKzpl//nOQCZ9ud2 4sUK0BNGiV3OReDZzBxxpEl0d45RP0VfKeFsFPgjUwi1Ac58iXqRnf/LCDeHwQ== Received: from ravel.localnet (aclermont-ferrand-653-1-222-123.w90-14.abo.wanadoo.fr [90.14.66.123]) (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 4f9XyW0xMmzs5l; Tue, 10 Feb 2026 20:21:23 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Gleb Smirnoff , Drew Gallatin Cc: freebsd-current@freebsd.org, src-committers@freebsd.org, ShengYi Hung Subject: Re: January 2026 stabilization week Date: Tue, 10 Feb 2026 21:21:11 +0100 Message-ID: <5959565.bE498FI5Hg@ravel> In-Reply-To: <7db87f3a-0106-42e1-a71a-34f4bc1c4a26@app.fastmail.com> References: <8518827.G18vQ0XA4d@ravel> <7db87f3a-0106-42e1-a71a-34f4bc1c4a26@app.fastmail.com> 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 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4304977.aWEtfRnraa"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart4304977.aWEtfRnraa Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; protected-headers="v1" From: Olivier Certner Subject: Re: January 2026 stabilization week Date: Tue, 10 Feb 2026 21:21:11 +0100 Message-ID: <5959565.bE498FI5Hg@ravel> In-Reply-To: <7db87f3a-0106-42e1-a71a-34f4bc1c4a26@app.fastmail.com> MIME-Version: 1.0 > In reading some of the docs for this, I got the impression that CPPC can = basically be 2 things >=20 > 1) A hardware controlled power governor, like our powerd or Linux's frequ= ency governors. > 2) A way to expose far more control over CPU frequency than pstates give = us (especially on AMD, where pstates generally only give 3 freqs) That's essentially that, yes. Point 1) is optional. Part of it is implemented by the so-called "autonomo= us mode". On both AMD and Intel, you have to set the desired performance t= o 0 to enable this mode. Any other value disables it. In autonomous mode,= you can use the EPP (Energy/Performance Preference) byte value to hint at = wanting more performance (towards 0) or more efficiency (towards 255). The= requested minimum and maximum performance (see next paragraph) may still h= ave an effect. Point 2) can give you more fine-grained control over power (performance, co= nsumption). First, you have to stop thinking in terms of frequency, switch= ing instead to abstract numerical performance levels. A level is a number = between 0 and 255, so you have at most 256 settings (in fact, 255 for the d= esired performance value, as value 0 is reserved for autonomous mode as sai= d above). The number of them that are really different is however hardware= =2Ddependent (on a specific CPU model). CPPC will normally report the hard= ware minimum and maximum values, and you have all values in-between at your= disposal to set the desired performance. However, besides the desired per= formance, there are two other controls: Requested minimum and maximum perfo= rmances (by contrast with the hardware limits, into which they must of cour= se lie). They limit the range in which the hardware is allowed to function= =2E The desired performance must lie between the minimum and maximum reque= sted. If all these values are not equal, the CPU is allowed (but not oblig= ed) to temporarily change its balance around the desired performance, which= is the other part of point 1). Setting all controls (minimum requested, d= esired performance and maximum requested) to the same value gives you some = exact performance level, which can further be tuned with the EPP value. >> For the future, we should probably eye at teaching powerd(8) about worki= ng with CPPC, (snip) > (snip) However, I think (2) would let powerd do a far better job and I'd = be very interested in getting CPPC to optionally expose more frequencies an= d not do any automatic governing. All CPPC controls I have mentioned are going to be exposed for AMD hardware= very soon (reviews have been validated, I'm still polishing and testing so= me and will commit tomorrow probably). Goal is to expose the same controls= for Intel hardware (which actually has some more, but that are tied to poi= nt 1)) in a second step. Then, what will be needed is to enhance powerd(8) to actually use these con= trols instead of setting frequencies (once CPPC is enabled, it's not possib= le to set frequencies, at least directly). Some experimentations will be n= eeded to find the right policies, as the spec leaves an important leeway to= hardware implementors. Policies may have to be tuned to the CPU brand, an= d even further to specific CPU models. E.g., on some AMD CPU I'm testing, = the EPP value has absolutely no effect (whether in autonomous mode or not),= and the size of the range of the requested minimum and maximum does not se= em to matter (that still needs more experiments), so basically only the des= ired performance has an effect. On other Intel CPUs I tested, the EPP valu= e has an important effect (in autonomous mode). =2D-=20 Olivier Certner --nextPart4304977.aWEtfRnraa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmmLkzcACgkQjKEwQJce Jid/TQ//a8Be0fH6NoH80o1XHmQf5SAn+jqeltTZSRYjiYFgFLLGUm0OsN9rFEx9 kuvxagmKsayAbwZJBuOxk2+m8xVDA7r4L910Y0adNHmSmAIckrsfnPCbETavsS/X BAt1QA5UwicKMhiRvRVut78NW3nUJcIXZybR97fHhZ1wZnteQRsdii+ZGcxs9f8c duivBTT/NLoP7EkrTWbESRcATdvxXCi3CuUhqG/px8Ro1m4Xzt2bDn2KixddPeWA JtkvbUHj1Zi/CuL69PY1Qi/3MEJnvdJTrcJC/cMyvW2vU+mczr0XkkLO17UdK7/U MGQhlAFkrZCU14UKRPjjkeQsn44s3lMwP/hzA4mIiNd566caorU/4aKMXnofaCrY sRU6YU/DyipGZ+8UbkEYVibQs35uSz488rzAcLEJWJNaoyrAaVOl+wq43wdI+4r7 MD4geluh7DcXKhui7uczhoTDoPUtSt3SIbiD2Ca/HnuRmBJayXVDkGzv5gG1ixI9 7DLWdW+8MCwNkPziiNw+0O1gUMKrAUQxlS8K0maXz+7EcLhdi/GgsLyEoNTUzqC6 UtUReB+myNedrTyeY6vmj/kg7JALlFtQBwmRbv4+qM5k8AaAk8dzZS5mNKQtMi2z 6xocja/JtbiASo6vC8flsEMnVeZ8/ufy/r2SvwhOzcpvKmuAjV8= =GPSP -----END PGP SIGNATURE----- --nextPart4304977.aWEtfRnraa--