From nobody Mon Jul 13 03:20:01 2026 X-Original-To: dev-commits-src-main@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 4gz73h1Yhjz6lRXM for ; Mon, 13 Jul 2026 03:20:16 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (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 4gz73f5Y4Kz3TKL for ; Mon, 13 Jul 2026 03:20:14 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of jrtc27@jrtc27.com designates 209.85.128.42 as permitted sender) smtp.mailfrom=jrtc27@jrtc27.com Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-493bb510ce4so18098925e9.1 for ; Sun, 12 Jul 2026 20:20:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783912813; x=1784517613; h=references:to:cc:in-reply-to:date:subject:mime-version:content-type :message-id:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=9LfuXCtm1dAzk/gvhIJSPLmUGDGjh+D0hepxaC8WcyQ=; b=TohrzEQAjghd/IBo/M63EU4yVBPemD+OyZe1cmgCNRPGfXT/734TeIbS4bzflne7cR urQPOEgcepKGGfEwHfkAQiaAs3JSOHUFuAOdKkBCGgr/9ZGTVHUJ4K10rvpjozX8k2Vj 1joDW+IRXcHhtuPVzUVW71g6PvaLG82C0qQpAhxaJuXFHo6xHygnSGGkwHPAgNdLNiS1 3QVFuVlCNT0G+O0n/cnN4mHUlEFv8W3adV6iRD08+JrE4ZlyMC0YYGzgW1765MjSknLS LiPJHGahs4gXjmu7J5fBe0wpw03iTuHd7tr1UKh3VoZlU5qA8PuC/tli6IPAfueFVIhD H5qQ== X-Forwarded-Encrypted: i=1; AHgh+RpFx4n0TkJ6g1wKJTYIE6uZmn6dtSmsmuOhu/M20whG5hMAiIMlbgBpfrGTvwRnnKyZw+drpZdHtlUPBB1AiYvVRXpkyQ==@freebsd.org X-Gm-Message-State: AOJu0YxkVbnwZkMLP6wvwgjbZ+gV/BcWg88K9bZvuKanPmg0CKEjoiKJ Picm49oNSitCYIFgBxFxhbuYXj6oaWZsAtZqy4CfdyT/iL9f5jv9he3xMnPaLg5rR/g= X-Gm-Gg: AfdE7cmCyD1qgxXNO+AbLkqSDrUkixqc3wnbos5JoKeBVeCB0BYx3YpQITTE7ZYD/2E 3w/2679s+IEftttMWQNJ3Qx1RWLNqgAW6wzzw3lLjjS2K/SdWtQxh5+1hZ4FzkuyvzjGnSfEdc2 H/t5+PQ58iJc1C4XhQixQdl/j2YHXYtbAZojEunsUxtlRvVS6lxKc08PwYMBVg1PszMlVIVLX79 DEfIoOEiEfjLteuSvGzRyFdh5p91IyDcxunzRB4loYj0R5nkhSVIgaB1ZoaYxROGt/DTEBiaF+G dPKj8ZGxwTDGAj4lxDw7/JoJlYZQb3l6N4VCtePd+GJzj7qtJQPL3GES/t20bRw+u9XSWZebpDK tIlCxnJy2v/dr+X5dJme8Z75wqAHzmi3vU6xdbJwyn2YSc+EpSsLY5xRcq2nQeDvfnJqGtTM4Zc 1NBd9ErJQkpXxrmfMvyEOSvNiE/SMJlNRNVF/oLeQQkR8ninkvJVHI9AfAyh0= X-Received: by 2002:a05:600c:6291:b0:493:bc31:b2ae with SMTP id 5b1f17b1804b1-49403e8f840mr458565e9.10.1783912813097; Sun, 12 Jul 2026 20:20:13 -0700 (PDT) Received: from smtpclient.apple (nat-184-161.net.cam.ac.uk. [131.111.184.161]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-493eb6f3b85sm532818005e9.2.2026.07.12.20.20.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Jul 2026 20:20:12 -0700 (PDT) From: Jessica Clarke Message-Id: <9F123195-C88F-4010-BAA8-1DF27FC7971B@freebsd.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_D533B230-6247-4334-A61E-A208E2694CA7" List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3893.100.7.1.1\)) Subject: Re: hwpstate_intel i386 build workaround [Was: Re: git: 7b26353a59d6 - main - hwpstate_intel: Disable package control on hybrid CPU] Date: Mon, 13 Jul 2026 04:20:01 +0100 In-Reply-To: Cc: Harry Schmalzbauer , ShengYi Hung , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org To: Adrian Chadd References: <6a1e7b3b.1a45a.91f6820@gitrepo.freebsd.org> <21a39777-c38e-4805-abdc-b1c19183bce1@omnilan.de> X-Mailer: Apple Mail (2.3893.100.7.1.1) X-Spamd-Result: default: False [-2.16 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.76)[-0.763]; MV_CASE(0.50)[]; FORGED_SENDER(0.30)[jrtc27@freebsd.org,jrtc27@jrtc27.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; FREEFALL_USER(0.00)[jrtc27]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.128.42:from]; RCVD_IN_DNSWL_NONE(0.00)[209.85.128.42:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[jrtc27@freebsd.org,jrtc27@jrtc27.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[dev-commits-src-main@freebsd.org]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[dev-commits-src-main@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_FIVE(0.00)[6] X-Rspamd-Queue-Id: 4gz73f5Y4Kz3TKL X-Spamd-Bar: -- --Apple-Mail=_D533B230-6247-4334-A61E-A208E2694CA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Is someone going to do something about this? It=E2=80=99s still broken, = though the i386 build errors are stacking up (I just took it down from 3 = known issues to 2, at least=E2=80=A6). If the code is going to exist in = the repo then we need to do better at actually making sure it builds, = and so I might make the controversial suggestion that, so long as i386 = kernel sources exist in main and are supported in at least one stable = branch, we should have at least one kernel config that=E2=80=99s part of = the default universe build, so we actually test the code rather than = finding out it=E2=80=99s broken when a user reports it or it gets MFCed. = This state of affairs doesn=E2=80=99t save effort, it just defers it, = and if anything makes it worse because people have to diagnose the = error, rather than it just be fixed from the start by the original = author. Jessica > On 27 Jun 2026, at 16:23, Adrian Chadd wrote: >=20 > please create a review for this? It sounds like they should've wrapped > it if #ifdef amd64 or something >=20 > -a >=20 > On Sat, 27 Jun 2026 at 07:19, Harry Schmalzbauer = wrote: >>=20 >> On 2026-06-02 08:42, ShengYi Hung wrote: >>> The branch main has been updated by aokblast: >>>=20 >>> URL: = https://cgit.FreeBSD.org/src/commit/?id=3D7b26353a59d66dc1bc611fd042a49b9e= 3bd13699 >>>=20 >>> commit 7b26353a59d66dc1bc611fd042a49b9e3bd13699 >>> Author: ShengYi Hung >>> AuthorDate: 2026-06-01 09:46:37 +0000 >>> Commit: ShengYi Hung >>> CommitDate: 2026-06-02 06:41:41 +0000 >>>=20 >>> hwpstate_intel: Disable package control on hybrid CPU >>>=20 >>> In package control mode, the performance of all cores depends on = the >>> most recent value written to the request field. If the last = write comes >>> from an E-core, all cores are forced to align with the E-core >>> performance level, resulting in significant performance = degradation. >>> Therefore, package control is disabled on hybrid-core systems. >>>=20 >>> Reviewed by: olce >>> MFC after: 2 weeks >>> Sponsored by: The FreeBSD Foundation >>> Sponsored by: Framework Computer Inc >>> Differential Revision: https://reviews.freebsd.org/D57377 >>> --- >>> sys/x86/cpufreq/hwpstate_intel.c | 21 +++++++++++++++++++++ >>=20 >>=20 >> In lieu of a proper fix, due to lacking skills, I'm working around = i386 >> incompatibility with this diff: >>=20 >> diff --git a/sys/x86/cpufreq/hwpstate_intel.c >> b/sys/x86/cpufreq/hwpstate_intel.c >> index db8600d7b89a..b9b68f1b14d0 100644 >> --- a/sys/x86/cpufreq/hwpstate_intel.c >> +++ b/sys/x86/cpufreq/hwpstate_intel.c >> @@ -321,6 +321,7 @@ sysctl_epp_select(SYSCTL_HANDLER_ARGS) >> return (ret); >> } >>=20 >> +#ifndef __i386__ >> static void >> intel_hwpstate_hybrid_cb(void *ctx) >> { >> @@ -328,11 +329,14 @@ intel_hwpstate_hybrid_cb(void *ctx) >>=20 >> atomic_add_32(small_cores, PCPU_GET(small_core)); >> } >> +#endif >>=20 >> void >> intel_hwpstate_identify(driver_t *driver, device_t parent) >> { >> +#ifndef __i386__ >> uint32_t small_cores =3D 0; >> +#endif >>=20 >> if (device_find_child(parent, "hwpstate_intel", >> DEVICE_UNIT_ANY) !=3D NULL) >> return; >> @@ -353,6 +357,7 @@ intel_hwpstate_identify(driver_t *driver, = device_t >> parent) >> if ((cpu_power_eax & CPUTPM1_HWP) =3D=3D 0) >> return; >>=20 >> +#ifndef __i386__ >> /* >> * On hybrid-core systems, package-level control cannot be = used. >> * It may cause all cores to run at the E-core frequency = because >> @@ -363,6 +368,7 @@ intel_hwpstate_identify(driver_t *driver, = device_t >> parent) >> intel_hwpstate_hybrid_cb, smp_no_rendezvous_barrier, >> &small_cores); >> if (small_cores > 0 && small_cores < mp_ncores) >> hwpstate_pkg_ctrl_enable =3D false; >> +#endif >>=20 >> if (BUS_ADD_CHILD(parent, 10, "hwpstate_intel", >> device_get_unit(parent)) >> =3D=3D NULL) >>=20 >> I know i386 is not supported anymore. >> Just in case anybody else wants to keep i368-stable/15 for bhyve = guests >> for example, where cpufreq(4) isn't attaching anyways. >>=20 >> Thanks, >>=20 >> -harry >>=20 >>=20 >=20 --Apple-Mail=_D533B230-6247-4334-A61E-A208E2694CA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Is someone going to do something about = this? It=E2=80=99s still broken, though the i386 build errors are = stacking up (I just took it down from 3 known issues to 2, at least=E2=80=A6= ). If the code is going to exist in the repo then we need to do better = at actually making sure it builds, and so I might make the controversial = suggestion that, so long as i386 kernel sources exist in main and are = supported in at least one stable branch, we should have at least one = kernel config that=E2=80=99s part of the default universe build, so we = actually test the code rather than finding out it=E2=80=99s broken when = a user reports it or it gets MFCed. This state of affairs doesn=E2=80=99t = save effort, it just defers it, and if anything makes it worse because = people have to diagnose the error, rather than it just be fixed from the = start by the original author.

Jessica

On 27 Jun 2026, at 16:23, Adrian = Chadd <adrian@freebsd.org> wrote:

please create a review for = this? It sounds like they should've wrapped
it if #ifdef amd64 or = something

-a

On Sat, 27 Jun 2026 at 07:19, Harry = Schmalzbauer <freebsd@omnilan.de> wrote:

On 2026-06-02 08:42, ShengYi Hung = wrote:
The branch main has been updated by = aokblast:

URL: = https://cgit.FreeBSD.org/src/commit/?id=3D7b26353a59d66dc1bc611fd042a49b9e= 3bd13699

commit = 7b26353a59d66dc1bc611fd042a49b9e3bd13699
Author: =     ShengYi Hung = <aokblast@FreeBSD.org>
AuthorDate: 2026-06-01 09:46:37 = +0000
Commit:     ShengYi Hung = <aokblast@FreeBSD.org>
CommitDate: 2026-06-02 06:41:41 = +0000

    hwpstate_intel: Disable package = control on hybrid CPU

    In package control = mode, the performance of all cores depends on the
=     most recent value written to the request field. = If the last write comes
    from an E-core, all = cores are forced to align with the E-core
=     performance level, resulting in significant = performance degradation.
    Therefore, package = control is disabled on hybrid-core systems.

=     Reviewed by:    olce
=     MFC after:      2 = weeks
    Sponsored by:   The FreeBSD = Foundation
    Sponsored by: =   Framework Computer Inc
=     Differential Revision: = https://reviews.freebsd.org/D57377
---
=  sys/x86/cpufreq/hwpstate_intel.c | 21 = +++++++++++++++++++++


In lieu of a proper fix, = due to lacking skills, I'm working around i386
incompatibility with = this diff:

diff --git = a/sys/x86/cpufreq/hwpstate_intel.c
b/sys/x86/cpufreq/hwpstate_intel.cindex db8600d7b89a..b9b68f1b14d0 100644
--- = a/sys/x86/cpufreq/hwpstate_intel.c
+++ = b/sys/x86/cpufreq/hwpstate_intel.c
@@ -321,6 +321,7 @@ = sysctl_epp_select(SYSCTL_HANDLER_ARGS)
=         return (ret);
=  }

+#ifndef __i386__
 static void
=  intel_hwpstate_hybrid_cb(void *ctx)
 {
@@ -328,11 = +329,14 @@ intel_hwpstate_hybrid_cb(void *ctx)

=         atomic_add_32(small_cores,= PCPU_GET(small_core));
 }
+#endif

 void
=  intel_hwpstate_identify(driver_t *driver, device_t parent)
=  {
+#ifndef __i386__
=         uint32_t small_cores =3D = 0;
+#endif

        if = (device_find_child(parent, "hwpstate_intel",
DEVICE_UNIT_ANY) !=3D = NULL)
=             &n= bsp;   return;
@@ -353,6 +357,7 @@ = intel_hwpstate_identify(driver_t *driver, device_t
parent)
=         if ((cpu_power_eax & = CPUTPM1_HWP) =3D=3D 0)
=             &n= bsp;   return;

+#ifndef __i386__
=         /*
=          * On hybrid-core = systems, package-level control cannot be used.
=          * It may cause all = cores to run at the E-core frequency because
@@ -363,6 +368,7 @@ = intel_hwpstate_identify(driver_t *driver, device_t
parent)
=             in= tel_hwpstate_hybrid_cb, = smp_no_rendezvous_barrier,
&small_cores);
=         if (small_cores > 0 = && small_cores < mp_ncores)
=             &n= bsp;   hwpstate_pkg_ctrl_enable =3D = false;
+#endif

=         if = (BUS_ADD_CHILD(parent, 10, = "hwpstate_intel",
device_get_unit(parent))
=             =3D= =3D NULL)

I know i386 is not supported anymore.
Just in case = anybody else wants to keep i368-stable/15 for bhyve guests
for = example, where cpufreq(4) isn't attaching = anyways.

Thanks,

-harry




= --Apple-Mail=_D533B230-6247-4334-A61E-A208E2694CA7--