From nobody Tue Feb 10 18:47:28 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 4f9VtS6Y6sz6RnJG for ; Tue, 10 Feb 2026 18:47:44 +0000 (UTC) (envelope-from jonte.puide@gmail.com) Received: from mail-oo1-xc31.google.com (mail-oo1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4f9VtS4dYLz43Td for ; Tue, 10 Feb 2026 18:47:44 +0000 (UTC) (envelope-from jonte.puide@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oo1-xc31.google.com with SMTP id 006d021491bc7-674181e5bb9so65008eaf.3 for ; Tue, 10 Feb 2026 10:47:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770749259; cv=none; d=google.com; s=arc-20240605; b=PyvMJSovlDkXRdI+y2QnNoKJR0WcMOVn5x+9YBL+Y6yZLskQ9YjOS/ywe2UOpEHiYK YTHw3Y3RkKi4KOqg6E0sdBkpY2UIOSVZiB0VkpArB6J+AZgFtIxqSR0LEr3Cfrg0gHVY hEW/8A7i5EePPDsI8JKfKcrcfzBHS2mt0CercSUSTXW0WLPoMTr29ppld8kN2VchLKT3 BNMb64gTUWY9AZAP/BCAaU9mxv5H4cXbdrZfRn5qXVAgBqBzasQZvc41EaPF3aUmIQwp OchJV6ofp9DSWUDyITMXGdLtyCvBOIFx/OwXs55ZwBHvSox2Dp86snlvuSCo3hAwwzhV 5QVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=8NaK5DMfg06usNOFAHF+3zGDBDVs1rGV+E3o6//1Z0w=; fh=EMG7PWiCOTWMgB23WOUsaHBr7NvXmSQsctpJg8ZVxss=; b=E0/q192Wtff0GUMGEhjhW6+2UPBtYqKtNfB0TEf5NapegWNP+LxL+ipGePzzJo8aFV HrCbwL97Va4YQuL77b9gI53MDk+gp1P6VbPTRt3LiHwKncdIHZ8WP3z34xQO6bjY4P3R 8ythrrZqGukLEPcJ1tC19gvmu+ZEqCqf5cyTxbQbbIZx7RjHxaUsA1BuYsERpH8VDFaM lRWMP9J/zDVnZiehYAEkW8FSWprBrisecN0QG4pcl1kIZeMF9+9myNImcZUcfsJeCg81 fn1NbZda2Stek1WvtW6+ZzkyUIs4sTONHa5Y9vSKvdOu9y0Vu/fBO+JfeiTSX7MgK/qD eQCg==; darn=freebsd.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770749259; x=1771354059; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8NaK5DMfg06usNOFAHF+3zGDBDVs1rGV+E3o6//1Z0w=; b=YQOZ3JDZ2Ljil2ImisPIxrzuTsJyKJ9GyBNyYkQUmloODQ1tHw7+Og4ExfZUb+0Mrv nyvSCke0wwk1ClPeIHe3zFW3Wh5OWwgPY6CDu+LjV6fyoUjtL2I15j97BxA/sV0oFXbz 2eA3770Aadkmh8dggEXtxYVylUZ8JpK98HyhYPIauMee9y/bGOAqKjgYilmO0rHSU4R+ 5NVo5O+w2HJ2oHLVMqtlBF7hJQ5MEyC4Y044VLljpQ8BhEJo46k9lkpurXzA3JJhe3ok HlV0QFq3Vlb8C3sQQ21VDuuURR4ctT+8aUpk1pGrN4ZTGzqjJJ2ZfiP5C120a+4u6zLJ 5tEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770749259; x=1771354059; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8NaK5DMfg06usNOFAHF+3zGDBDVs1rGV+E3o6//1Z0w=; b=Nj/5l+ssPvpElnU7Lhz0/UGXEVz4luY5Qt+cgy9RyM+CF58kRo7GeR6QN29HSl5fZF AcmIBcC1XUWk5YajH0VZM03DDHM2/OgpVM/iUwHHm6M7ywX+uVD57kNgTXtUB9Mp/d3u WcM2/azunFsdxzOhEwlozHXslveWdUlgSAKtz/cItA431aSzcfq1eCgECrxCjYS+UHfF x4mjZU7qkejQgoPVEM2tWsY0pL9+UOBsqx9m/CAtzfrsSaCZUYBJ5IJiAf/G5U1GUew4 sj2Rd4odxl+eWqEwCtontnY/Gki0SNWV+95rWwNV452DSHsCWR3GKYBpeKaDrqaSpEnZ /xNw== X-Forwarded-Encrypted: i=1; AJvYcCWk+y4Sidcxz7eQ/NUv/T4jIAPRXpksGoX85/buWs2+cqju7oBP7q8I1Cvpu6+/myuf0VgprbjSRZIhWIQ7cRA=@freebsd.org X-Gm-Message-State: AOJu0YwccONd/cjIFXNvqpCGVvgvonhYpp/ST7dYWiaf9YWDSbosJ4ml +z5lny4BeNUCeXXrQAv2pGLzdjmj2o+d4inaoVIS9e73in9MVoQ6iJfNHsS3D77nLe/5Nz2m5DP T4Z9ZRlKfCEoh8mlit+qfVQt8i3D8Kbhoy0iP X-Gm-Gg: AZuq6aK+DGuzy+Bzejsn0b5lowWV9kmC17SalmNV85e8xk5NZjqPvdQ6ebosfQM8jL4 A22ZeGVNLevfUckm6ZwVhHW/DCfxH583Vv3uH1HxBrz08kjG96X6DF6tC8yv9Q4XO1lMkE0PdsR aiTDhMU177dLgC+FkcvQwMMuo+14kP1USqZy5Gjkwyu9IDtmQdexcP9jp5FDiVg+D7ubdUwVWPW xCuMcbUtQi6nS8p9YlSPgzEWlgz1cAMgqDAKQGDQPn+368OF0wxXJ4drpksKVuzdGycHyz9EHBT fiS3g3L0gq0zuCM/dzUejBRdeDh+furigfm0HRb7Sh44Vnqu4JA= X-Received: by 2002:a05:6820:4813:b0:66a:9d34:6cc0 with SMTP id 006d021491bc7-6743b4bac35mr7687eaf.27.1770749258666; Tue, 10 Feb 2026 10:47:38 -0800 (PST) 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 References: <2329920.sMrx5ctUpN@ravel> <6197e075-212f-4260-b437-902e06d1002b@app.fastmail.com> <8518827.G18vQ0XA4d@ravel> <7db87f3a-0106-42e1-a71a-34f4bc1c4a26@app.fastmail.com> In-Reply-To: <7db87f3a-0106-42e1-a71a-34f4bc1c4a26@app.fastmail.com> From: Jonathan Puide Date: Tue, 10 Feb 2026 19:47:28 +0100 X-Gm-Features: AZwV_QjAoEmQE6V0kLvHFOGtUv1lRJcz7vpR-YfiMPdEshsQVGaQXmIfyYgjZas Message-ID: Subject: Re: January 2026 stabilization week To: Drew Gallatin Cc: Olivier Certner , Gleb Smirnoff , freebsd-current@freebsd.org, src-committers@freebsd.org, ShengYi Hung Content-Type: multipart/alternative; boundary="0000000000008c97ad064a7cb0af" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4f9VtS4dYLz43Td X-Spamd-Bar: ---- --0000000000008c97ad064a7cb0af Content-Type: text/plain; charset="UTF-8" On my system, powerd functions just fine. Powerdxx too. Maybe it's just my system though. I feel like powerd and powerdxx really does the job well. T, 10. veebruar 2026, 19:45 Drew Gallatin kirjutas: > > > 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 > --0000000000008c97ad064a7cb0af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On my system, powerd functions just fine. Powerdxx too. M= aybe it's just my system though. I feel like powerd and powerdxx really= does the job well.

T, 10. veebruar 2026, 19:45 Drew G= allatin <gallatin@freebsd.org> kirjutas:

On Thu, Jan 29, 2026, at 4:09 PM, Olivier Certn= er wrote:
> On Intel, and now on AMD, it seems that CPPC is far worse than powe= rd (*).

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

> (...) And high settings use more pow= er.

But providing better performance, or not?



I certainly don't have= plans to remove that.=C2=A0 When talking about recommending CPPC, I was th= inking about the default value we wanted to have for the new 'machdep.h= wpstate_amd_cppc_enable' tunable, but not about removing it.=C2=A0 = 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 th= at instead of trying to set frequencies directly (which cannot really work = with and basically defeats the point of CPPC) it would instead tune the des= ired performance value (and possibly the min and max ones as well).=C2=A0 P= erhaps 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 govern= ors.
2) A way to expose far more control over CPU frequency than = pstates give us (especially on AMD, where pstates generally only give 3 fre= qs)

I'm not at all interested in (1), as I thi= nk powerd or something like it does a far better job at trading off power a= nd performance then CPPC on both Xeon and EPYC.=C2=A0 =C2=A0However, I thin= k (2) would let powerd do a far better job and I'd be very interested i= n getting CPPC to optionally expose more frequencies and not do any automat= ic governing.

Drew
--0000000000008c97ad064a7cb0af--