From nobody Mon May 25 13:02:57 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 4gPGJy2QzRz6fMqW for ; Mon, 25 May 2026 13:03:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 4gPGJx6Gpqz3STH for ; Mon, 25 May 2026 13:03:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x433.google.com with SMTP id d2e1a72fcca58-82fbdd60b64so7993999b3a.3 for ; Mon, 25 May 2026 06:03:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779714191; cv=none; d=google.com; s=arc-20240605; b=NCyhvRd7hGz5zgD+mAX/LaRiopvlgYEo7ebmI2UDC4gGLxHT9FTtc5TVlSYudQg60G QiEcm4Wu6epz0CnnMyv/uy04HnAPi+vMVgaQNxma4RI2xU209gI5w75Z6WHs/pqVREeu Fydr0oLhbPndskFRYBIZsmSBduE4m2HM1l1xuLVJwPefsiTjmuV4v3NjYifdC+s51gfc HRNj0cWPGw+pbQ2qle/8p0Zr722339KAAxXIOAO4L/wdmPeOoZkCiV3uuLY1iygStVrp EaTogH1u8zd2tdaEN/1xdabC3JGxt4dIiJo2LrEjPgjzb31GHm78aSe5jOvmf3keEu9c oa9g== 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=nJz8sCDueT3+A+tjTziCkE3hi+VI/CS8SvvN+DOU6QA=; fh=pHrB3UxBKYkTqf/KYgf/Y7vnaGrpjskIJp98RRhE3Qk=; b=NUl5AjSInA3+6eQbFsubTUNem0bBeWzUYpbYF+XO17RtGHsSXuQeDF7Lqso5eAmIC+ nJ3hKSZvyFUmMc4GAISue1M/J4lHUYihr3Q1UZzr6uVuNx+zvgN70D8YXv3QiAPtevAI QJC9goNBXV3uLAZfNkMKoYnafDCMCdePNnLYgbZ7dJawD6b6U9K34jZo3uA6c4kOdYLC RWAA3e8hBJB22jd0w0TfEnqfH9GD5K3ORbevWQdk8JNAC0irMCuYBmugHqB+VGwngM0B BS+T/f7bBjh2c7Rcc2s4+1RRj4nhpN9dbK2vfmJQlDqXFCtie+z/2q8hpNBYrjAcvBEh VMWQ==; darn=freebsd.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20251104.gappssmtp.com; s=20251104; t=1779714191; x=1780318991; 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=nJz8sCDueT3+A+tjTziCkE3hi+VI/CS8SvvN+DOU6QA=; b=mDlLHsjW8gH6D5Xt3xjZRwOhFTP4q4zyJzQEdJmb97WWLnoOFgzfuYCu4jDe4SB/0F JIdcuPR0TdD/9zRcJC7ph+29DXhdeNMUecxJ8jyXCLce8dAeS2u6pzgzq8e1HTcVXfL/ vT+cc6fL21eGUfQx2lrNQAZg5x0kM5b1L1+valznhmkx3PjYKuVznuJ5MPeK/b+LkES0 H8vSEJZUEp55T7CNnVUi5jySbRfGnrWQOzYkWNCqCYsLP/ccbsbfzqan0LX4lKHEdPwl P0+qiyoCN9V9ldAP+ClDMsBsIjnADkkgPZn4ujWhjfB3m7J/Ybe4M86ACglZmlyfkoKQ 7F3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779714191; x=1780318991; 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=nJz8sCDueT3+A+tjTziCkE3hi+VI/CS8SvvN+DOU6QA=; b=W/HTNTz7UYvB7b3prFVHq7XCOQtunt5RdjEbH9fdmcFAcH1TXuBEFYQyRtj3eZGaXS vXICrCoKrJsgwXHl2NtT0O1a35VeyZ7xlTy8WLQ2tDTByU3IewYelNWzT5SYiEP3wzoh b2OgqC0ipbosohmFWtNXOkPppTbCosPZdWc95gm4IBFw4orin2qkwVnSxaaKYmvG7rMu 5qfY1CnX7HWq/Q2I8ECxaOIE0GK0NoNhfQmRIbpn1ZcOWXmFCvTPKfhLy9mvZO7GYb1H 2ZTBjPAhLZpMNhdBLoWkZ48OtGCSsZCkwARSiKUrUVfWcT2NbPQXxpzwqNECmW5X5vp2 rZ3w== X-Forwarded-Encrypted: i=1; AFNElJ9ZbmUtSJ9h0axvpAi36d5SrNuULmfvyJ/VP+OAV9qmNu7zcBAFPw5RuNCu6zTXtuOgMp6TdzzM8EHMLrQ3kMI=@freebsd.org X-Gm-Message-State: AOJu0YzprlMjdl06ftqDFFjIlwk8KGznXuWMi8xPxEQjUuySzEOeJ7Hx LMu+h69OsmPbDktpAyE/pPdIGqd+PFaORaiDgXZiPpPSBvNCH105FFzNOEqahRf0KPN2pUUgDF0 iH/FET04IHuvhSXbIl8ifaP7Q1X7PNRl28SXbxjIBzg== X-Gm-Gg: Acq92OG9Yel+cjx/kpGkUr9B/Rf/Z1+nglj4q2QEb4rZWqFVFsjcLCNu97xhMQT0yNe krji/BM0pObFDZgvuhQUMyLT2zMf8ntEMQvzvhi+L5u4enXQfwxMu6zJiLtxFxZa9T9L0hkcdmN /GTEpYxFctuiLHB3eIHnyonbm36UDDwKBZZyUfqnl5SReiART6ljlVoDH5Mz4HER1YlcdWhh+CH rH02Z1JIjine0oD6tkdKINAYCyTwBkRDPBW0biC2tkwZyJ80hqBfFjJGCxhvy3nTf7MjoLiF/nM YndsTsnpUw9jyyYyA9nEO6eDQwCWpUeZcEgQsOjmJw1xNcg= X-Received: by 2002:a05:6a00:3a0d:b0:82d:162c:581f with SMTP id d2e1a72fcca58-8415f3ba3c0mr13883476b3a.48.1779714190799; Mon, 25 May 2026 06:03:10 -0700 (PDT) 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 References: <1978836.vR5SVPPSqJ@ravel> In-Reply-To: <1978836.vR5SVPPSqJ@ravel> From: Warner Losh Date: Mon, 25 May 2026 07:02:57 -0600 X-Gm-Features: AVHnY4IH-1fd1S_ExSuqsuZiz6Jqj8qupfgfTq9R4UmylWzw4G_GFi89bzU-ApI Message-ID: Subject: Re: AMD, CPPC, etc To: Olivier Certner Cc: Chris Torek , Adrian Chadd , freebsd-current , ShengYi Hung Content-Type: multipart/alternative; boundary="0000000000002504550652a40003" X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4gPGJx6Gpqz3STH X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated --0000000000002504550652a40003 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, May 25, 2026, 5:48=E2=80=AFAM Olivier Certner wr= ote: > 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=3D0, it goes back down, so thi= s > > > 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 t= o > 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.h= tml > - https://reviews.freebsd.org/D55253 > > > I'd much prefer that powerd bump the CPU frequency up to the highest (e= g > 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 wi= th > 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 default= s > (maximum performance =3D> 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 t= o > 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 t= oo > 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. > At work, we run powerd on all our video streaming servers to save power by ramping the cpu frequency up in times of high demand, and then back down for low demand times.... it saves a lot of power. But to interpret our performance data, we have to record the settings since 90% cpu at 800MHz is way different than 90% at 3GHz... whatever we do here has to be observeable= . Warner How does CPU frequency selection and default values work on powerpc64/ARM? > > Regards. > > -- > Olivier Certner --0000000000002504550652a40003 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, May 25, 2026, 5:48=E2=80= =AFAM Olivier Certner <olce@freebsd.= org> wrote:
Hi,

> > Commit 80d32a6b1d73 (hwpstate_amd(4): CPPC: Switch the default to=
> > maximum performance) cranks my 7950-based system from its 90-to-1= 00
> > watt idle draw up to 150+ watts. If I set
> > dev.hwpstate_amd.0.desired_performance=3D0, 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.=C2=A0 We have plan= s to change it.=C2=A0 Actually, we wanted to produce a PoC at AsiaBSDCan tw= o months ago, but this was thwarted by illness there...=C2=A0 See pointers = below.

I won't have time to devote to this until the hackathon after BSDCan.= =C2=A0 I don't know about ShengYi, it seems he's busy with other to= pics.

> 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.or= g/archives/cu/2026-February/009918.html
- The end of = https://lists.freebsd.org/archives/freebsd-hackers/2026-February/005774.htm= l
- https://reviews.freebsd.org/D55253

> I'd much prefer that powerd bump the CPU frequency up to the highe= st (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 ena= bling CPPC by default in hwpstate_amd(4) (which perhaps we did prematurely)= .=C2=A0 hwpstate_amd(4) has been our driver for regular P-states from the s= tart (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 suppor= ts CPPC for Intel processors (and not P states), does, which is to keep Int= el's initialization value for EPP (as mentioned just above), i.e., some= balanced setting.=C2=A0 I have not checked whether Intel implements CPPC o= n its desktop processors.

Going further, I have been considering changing hwpstate_amd(4)'s defau= lts (maximum performance =3D> some balanced setting (which itself is not= that well-defined for CPPC both in theory and apparently in practice on AM= D 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 co= ntroversial change.=C2=A0 I guess people do not run powerd(8) on desktop ma= chines (and maybe a number of them do not run powerd(8) either on not too o= ld Intel laptops due to hwpstate_intel(4)).=C2=A0 We might consider switchi= ng to a model where powerd(8) is always run by default, but that probably r= equires significant work on powerd(8) to make it much smarter.=C2=A0 On a r= elated note, going forward, we might want to move part of powerd(8)'s l= ogic into the kernel.

At work, we run powerd on all our video streaming serv= ers to save power by ramping the cpu frequency up in times of high demand, = and then back down for low demand times.... it saves a lot of power. But to= interpret our performance data, we have to record the settings since 90% c= pu at 800MHz is way different than 90% at 3GHz... whatever we do here has t= o be observeable.

Warner=

How does CPU frequency selection and default values work on powerpc64/ARM?<= br>
Regards.

--
Olivier Certner
--0000000000002504550652a40003--