Re: [PATCH] cpufreq: intel_pstate: Disable SMT when hybrid systems are enabled

[Yaxiong Tian]

在 2026/1/28 00:08, Rafael J. Wysocki 写道:
> On Mon, Jan 26, 2026 at 3:15 AM Yaxiong Tian <tianyaxiong@xxxxxxxxxx> wrote:
> > 在 2026/1/24 04:12, Rafael J. Wysocki 写道:
> > > On Fri, Jan 23, 2026 at 2:20 AM Yaxiong Tian <tianyaxiong@xxxxxxxxxx> wrote:
> > > > 在 2026/1/22 23:55, Ricardo Neri 写道:
> > > > > On Mon, Jan 19, 2026 at 03:41:18PM +0800, Yaxiong Tian wrote:
> > > > > > When hwp_is_hybrid && !sched_smt_active(), the driver enables
> > > > > > hybrid_capacity_scale and disables ITMT. According to the original code
> > > > > > logic, these related actions are one-time operations; therefore, I
> > > > > > believe the original design intent did not support dynamic runtime
> > > > > > switching.
> > > > > >
> > > > > > However, SMT can be toggled via related interfaces in /sys. When SMT is
> > > > > > enabled, the system is no longer hybrid, and the original settings become
> > > > > > incorrect.
> > > > > Indeed I was able to enable SMT siblings:
> > > > >
> > > > >         $ echo on > /sys/devices/system/cpu/smt
> > > > >         $ echo 1 > /sys/devices/system/cpu/cpu1/online
> > > > >
> > > > > > To resolve this confusion, permanently disable SMT by calling
> > > > > > cpuhp_smt_disable().
> > > > > IMHO, the user should be able to enable SMT back if she or he chooses to. Instead,
> > > > > the sched domains should be rebuilt with asym packing and without asymmetric
> > > > > capacity.
> > > > Yes, I also agree with this viewpoint.
> > > I don't agree though.
> > >
> > > > I think a better solution is to
> > > > place it within cpufreq online for heterogeneous judgment and to clearly
> > > > address sched domain rebuilt and asymmetry issues.
> > > Maybe in theory, but in practice the EAS-related code in intel_pstate
> > > really only targets systems with no SMT.
> > >
> > > While it is possible to use it on SMT systems with SMT disabled, I
> > > really wouldn't recommend doing that beyond debug/diagnostics and no,
> > > it is not sufficient to disable stuff when SMT is re-enabled, you'd
> > > basically need to unregister the driver and register it from scratch
> > > in that case.
> > Thank you for your explanation. It seems I didn’t read the document
> > carefully enough before.
> >
> > > > I ran some tests the
> > > > day before yesterday and encountered a few locking problems. I will
> > > > publish the patch a bit later.
> > > Given the complexity involved, I don't think it is worth the effort.
> > >
> > > I can apply this patch though.
> > Um, although I've already done it, I agree with your point.
> >
> > Besides, I don't think this patch is very suitable either, because I
> > supposethat on a n system without SMT, the SMT-related|/sys|interface
> > should indicate unsupported (though I don't have such a machine).
> >
> > Moreover, based on the previous discussion, would it be more appropriate
> > to use !cpu_smt_possible() instead of !sched_smt_active()? After all,
> > the original design was intended for systems without SMT. If you also
> > agree with this perspective, I can test it on a machine with SMT.
> Yes, please!
>
> Using cpu_smt_possible() instead of sched_smt_active() would be the
> most straightforward way to address this, provided that it works.


Okay, I've tested after making the modifications, and everything works fine.

On a machine with SMT (Simultaneous Multithreading):

1.

   With|nosmt|added to grub, CAS and EAS are not enabled.

2.

   With|nosmt=force|added to grub, CAS and EAS are enabled, and users
   cannot change the SMT setting.

Since I don't have access to a machine that does not support SMT, I 
analyzed the scenario for non-SMT machines. There should be no issues at 
all—when SMT is not supported, CAS and EAS will be enabled, and users 
cannot switch to SMT. If any problems arise, they likely need to be 
addressed by fixing the|cpu_smt_possible()|function.

I’ve already released the relevant patch:

 https://lore.kernel.org/all/20260128031521.389765-1-tianyaxiong@xxxxxxxxxx/