From nobody Tue Feb 10 18:45:26 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 4f9VrF3Dlqz6Rmss; Tue, 10 Feb 2026 18:45:49 +0000 (UTC) (envelope-from gallatin@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" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4f9VrF2j78z422B; Tue, 10 Feb 2026 18:45:49 +0000 (UTC) (envelope-from gallatin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1770749149; 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=N/bMwz2RhM7QHvBhmBD9p9Vjn3gaPpTI/BoLvvA4178=; b=eq0ifxftPJ5eUN4s3reU5ALfC2lluEPyXeDU6BZSp5EyLXvUs5ViFugUpazhuoXUPdeKdW /YV8s7zvbPoZ6mFecp/CrKjU/urAyumyDqlr05to4lMiYN1yKj0Mdq1ts8pc1nivKkKVpJ fZfNrtFxn6/EU9mo8s8eJKowag5M/CJRpuLhJDQYvK7Gk/lGIqEl3f7O62zmO1tW4wDVFQ NiulSkUgZW91ZKW9nhhdrvUDQHr5cJtHJUn59aREUeQWaoGxRnZjCKAFfepa7lZpEWbux/ FVNwp6E2rW88TmCAhWwurmV27rhcSH5xa3x1d1CqQaGXcdkPFP8vitJM8RmQfA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1770749149; a=rsa-sha256; cv=none; b=A4oRw4hAJe03/q5OUBj+HyHzTFaquMO+DbtcShT9UqPsVVHhpYhTGkMEDHWAQ2Aog3KUfC zhLt9dLf5YkBRMsA0Lbr+6qfYu29+hAPG5cUj+VmpNQVbP+pKgfAIH75uSulN/DdLq3MCq jEuFLqXlp15D57uNCBPgF9uGqi5KFyoyTjEEJ8/QFG2pvNJoqIqGTKcVbC/B/OLhyYihZ5 f9dDEjJuc5UGDzYfIfwQznU2zXqa96PwCqGm3T8y4CB2kljjHf7pkmMa2YD11aRcqdsBV4 ZY0nfNi4cv13sdkYhuTVay2uWrLlIjRL5BUYjHzJPXrzEscF6jJd07aCP1X1Wg== 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=1770749149; 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=N/bMwz2RhM7QHvBhmBD9p9Vjn3gaPpTI/BoLvvA4178=; b=oT2xjBpEeHKuemf8ur7FiLCLZHcYs/v7WIz0jnhkl8teg/QcBxP05q8uoNXHuUMuHk4zRm fD/J+LDLiJuLQy8G4BzycWiz85oyTk+QSNaZV+XxXI23lsOs7APmNWVPUHG5lyFs23mYC7 KWBOv5qkn3Ea5GM620g2FOwfDju8AGjmhieFk2vqIjHCHsGJOk8iYCb/BtVj+fmBwCExug I9S9YKTKV2nl7bPHLkV+mJ6ukub29shNebPcwFtWExgDKgwPtkLT880VrN+KX8H8rYNznX gOTxvI3sjQbhj/sm1CoD4+pynBbzOap6Z5Fat6NvnYtIgYAs4lTyWLTVyPPKsQ== Received: from fauth-a1-smtp.messagingengine.com (fauth-a1-smtp.messagingengine.com [103.168.172.200]) (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: gallatin) by smtp.freebsd.org (Postfix) with ESMTPSA id 4f9VrF17Q2zp3M; Tue, 10 Feb 2026 18:45:49 +0000 (UTC) (envelope-from gallatin@freebsd.org) Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfauth.phl.internal (Postfix) with ESMTP id F33B7F4006C; Tue, 10 Feb 2026 13:45:47 -0500 (EST) Received: from phl-imap-02 ([10.202.2.81]) by phl-compute-05.internal (MEProxy); Tue, 10 Feb 2026 13:45:47 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvtddtgeefucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepofggfffhvfevkfgjfhfutgesrgdtreerredttdenucfhrhhomhepfdffrhgvficu ifgrlhhlrghtihhnfdcuoehgrghllhgrthhinhesfhhrvggvsghsugdrohhrgheqnecugg ftrfgrthhtvghrnhepieejveffieejiedukeejffejfefhlefgudfgteelteekueduheev ffevfedvleevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepghgrlhhlrghtihhnodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqddu feefheelvddvudeiqddvleehtdegudekgedqghgrlhhlrghtihhnpeepfhhrvggvsghsug drohhrghesfhgrshhtmhgrihhlrdgtohhmpdhnsggprhgtphhtthhopeehpdhmohguvgep shhmthhpohhuthdprhgtphhtthhopegrohhksghlrghsthesfhhrvggvsghsugdrohhrgh dprhgtphhtthhopehfrhgvvggsshguqdgtuhhrrhgvnhhtsehfrhgvvggsshgurdhorhhg pdhrtghpthhtohepghhlvggsihhushesfhhrvggvsghsugdrohhrghdprhgtphhtthhope holhgtvgesfhhrvggvsghsugdrohhrghdprhgtphhtthhopehsrhgtqdgtohhmmhhithht vghrshesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: i41414658:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id A5ABC700065; Tue, 10 Feb 2026 13:45:47 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface 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 X-ThreadId: AQpxQpBrI0Yc Date: Tue, 10 Feb 2026 13:45:26 -0500 From: "Drew Gallatin" To: "Olivier Certner" , "Gleb Smirnoff" Cc: freebsd-current@freebsd.org, src-committers@freebsd.org, "ShengYi Hung" Message-Id: <7db87f3a-0106-42e1-a71a-34f4bc1c4a26@app.fastmail.com> In-Reply-To: <8518827.G18vQ0XA4d@ravel> References: <2329920.sMrx5ctUpN@ravel> <6197e075-212f-4260-b437-902e06d1002b@app.fastmail.com> <8518827.G18vQ0XA4d@ravel> Subject: Re: January 2026 stabilization week Content-Type: multipart/alternative; boundary=351c5c71c81845cfb278a5adbd237b71 --351c5c71c81845cfb278a5adbd237b71 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, Jan 29, 2026, at 4:09 PM, Olivier Certner wrote: > > On Intel, and now on AMD, it seems that CPPC is far worse than powerd (*). > > That must depend on workloads and objectives then, since I've had the opposite experience on laptops in terms of latency. > > > (...) And high settings use more power. > > But providing better performance, or not? The same, not better. But statically setting cppc tunables so the performance is as good as powerd's performance means far more power is consumed when we are close to idle. > > So the ability to let software control frequency is something that I don't want to loose. > > I certainly don't have plans to remove that. When talking about recommending CPPC, I was thinking about the default value we wanted to have for the new 'machdep.hwpstate_amd_cppc_enable' tunable, but not about removing it. IMO, this tunable is here to stay (it might just change form at some point). > > I also encourage you to give a shot at the patch in PR 292615, in order to see how the new knobs (min & max performance, desired performance) can affect your observations, even if after what you reported that may look unlikely. > > For the future, we should probably eye at teaching powerd(8) about working with CPPC, so that instead of trying to set frequencies directly (which cannot really work with and basically defeats the point of CPPC) it would instead tune the desired performance value (and possibly the min and max ones as well). Perhaps with that combination we could get the best of both worlds (software + hardware tuning), at least for some workloads. In reading some of the docs for this, I got the impression that CPPC can basically be 2 things 1) A hardware controlled power governor, like our powerd or Linux's frequency 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) I'm not at all interested in (1), as I think powerd or something like it does a far better job at trading off power and performance then CPPC on both Xeon and EPYC. 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 and not do any automatic governing. Drew --351c5c71c81845cfb278a5adbd237b71 Content-Type: text/html Content-Transfer-Encoding: quoted-printable


On Thu, Jan 29, 2026, at 4:09 PM, Olivier Certner wrot= e:
> On Inte= l, and now on AMD, it seems that CPPC is far worse than powerd (*).

That must depend on workloads and objectives then, = since I've had the opposite experience on laptops in terms of latency.

> (...) And high settings use more power.

But providing better performance, or not?

The same, not better.  But statically= setting cppc tunables so the performance is as good as powerd's perform= ance means far more power is consumed when we are close to idle.

> So= the ability to let software control frequency is something that I don't= want to loose.

I certainly don't have plans to= remove that.  When talking about recommending CPPC, I was thinking= about the default value we wanted to have for the new 'machdep.hwpstate_amd_cppc_enable' tunable, but n= ot about removing it.  IMO, this tunable is here to stay (it might = just change form at some point).

I also encoura= ge you to give a shot at the patch in PR 292615, in order to see how the= new knobs (min & max performance, desired performance) can affect y= our observations, even if after what you reported that may look unlikely= .

For the future, we should probably eye at tea= ching powerd(8) about working with CPPC, so that instead of trying to se= t frequencies directly (which cannot really work with and basically defe= ats the point of CPPC) it would instead tune the desired performance val= ue (and possibly the min and max ones as well).  Perhaps with that = combination we could get the best of both worlds (software + hardware tu= ning), at least for some workloads.

In reading some of the docs for this, I got the impression that CP= PC can basically be 2 things

1) A hardware cont= rolled power governor, like our powerd or Linux's frequency governors.
2) A way to expose far more control over CPU frequency than pst= ates give us (especially on AMD, where pstates generally only give 3 fre= qs)

I'm not at all interested in (1), as I thin= k powerd or something like it does a far better job at trading off power= and performance then CPPC on both Xeon and EPYC.   However, I= think (2) would let powerd do a far better job and I'd be very interest= ed in getting CPPC to optionally expose more frequencies and not do any = automatic governing.

Drew
--351c5c71c81845cfb278a5adbd237b71--