From nobody Mon Jul 13 03:20:01 2026 X-Original-To: dev-commits-src-all@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 4gz73h3cFGz6lRYs for ; Mon, 13 Jul 2026 03:20:16 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (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 4gz73f5N0bz3TVN 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.52 as permitted sender) smtp.mailfrom=jrtc27@jrtc27.com Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-4921eed3fa2so24244295e9.0 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=OdV3uC6nz9ZjucKUEf2iI3MpsiSoUzZdP5MOCUjeM14jMITVmkvbdWUy6umVtFrDkQ sxvhhInpsk/AxS49t6QxGj4WEyYaZjBqSYrEboeDXhMlHhKAwgZhfRBDri3hxi65MKsh 7i5C191kFUJzzZeY9U75sL6F6CT2ERQNhZYqFG8nuIg7eg84Mx2KL4qPJR/PpQEgWXm1 vhCOJICYXqNGDRF738EnDgl8DUiz/5J96Yg2BWWA9jjPZMVYLDHQuD/1PBEfZFVvSOKc LuHxQex0MStsbs4ujNW64crf9qtWr7ifkQ1pb1eHPVMsWVtftGN9xctGk77JNeuQcgN4 T+Kw== X-Forwarded-Encrypted: i=1; AHgh+Rqw25y2y2rzzTE0gdxoEQ8elr4hYbQsnEk1O662muPEhVrrVJdP0UXQX5cJFGAOQcVxsJW0TjnPF4aAeF3GBqY9BZDE@freebsd.org X-Gm-Message-State: AOJu0YzwaWfeClaAEoK/bWIA/fQvC8qPtlqOtw/cAz8HG/lTQ1zL6FX6 8nsB+b7yAtuin3bP2z6bh7Xe1JXq44ajytdO9CjK/wXMGG3fqUwyLu3bkP2Z6Q2TCV51NEKowrG n7WV61a4= X-Gm-Gg: AfdE7cm28yrL7yxlNSBMaXrZU8Sm3kb2W6W9NyEglaEBfGZPaDkVRqNazp+grHrLpI9 OGiCUfXmmfyrXnzgZINJGYL2z8onR2n+W51xV8w7Bvc0Ux3Ho7BgjlFjTYa5HqbjtNj+v1CS4WA gedj0bxJrihe0HUYz5Cf3REraMPaSj6qls+DFMoYIObltsHErGlMVYWkXePtBoJC+CW7IKjlRpW JzmuL36sM5cU+S2U4yw0lVfDK7OWs4YAaf0YLzxxp/RRf1dwd3rnH9Tx4ghd/37mQtz+oOJQeBj l/TgWbwEszH/n4AHpy9XfSuF0UCltOH1QfJ5+yyW+N+NWMsQt9szVTmwheYRVONd6KiVH/kWp1T 65+OWYY4YhWQdMrFYVVoTQRhoteJKk68Cag+71O9zl67pGQJIACZvYAI3jIyIX0aS7Kq878PGQ+ MaxNERUVZz08TMx29dMWo76ovcrb1QrZ9ylh19+QSe11p0eBUSFkFQTdgMbjM= 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 all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@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.52:from]; RCVD_IN_DNSWL_NONE(0.00)[209.85.128.52: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-all@freebsd.org]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[dev-commits-src-all@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_FIVE(0.00)[6] X-Rspamd-Queue-Id: 4gz73f5N0bz3TVN 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--