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

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

[Yaxiong Tian]

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.

To resolve this confusion, permanently disable SMT by calling
cpuhp_smt_disable().

Fixes: 929ebc93ccaa ("cpufreq: intel_pstate: Set asymmetric CPU capacity on hybrid systems")
Signed-off-by: Yaxiong Tian <tianyaxiong@kylinos.cn>
---
 drivers/cpufreq/intel_pstate.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index ec4abe374573..d0274a3ece2d 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -1163,6 +1163,11 @@ static void hybrid_init_cpu_capacity_scaling(bool refresh)
 	 */
 	if (hwp_is_hybrid && !sched_smt_active() && arch_enable_hybrid_capacity_scale()) {
 		hybrid_refresh_cpu_capacity_scaling();
+		/*
+		 * Permanently disable SMT to prevent confusion caused by users
+		 * enabling SMT via /sys.
+		 */
+		cpuhp_smt_disable(CPU_SMT_FORCE_DISABLED);
 		/*
 		 * Disabling ITMT causes sched domains to be rebuilt to disable asym
 		 * packing and enable asym capacity and EAS.
-- 
2.25.1

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

[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.

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

[Yaxiong Tian]

在 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 think a better solution is to 
place it within cpufreq online for heterogeneous judgment and to clearly 
address sched domain rebuilt and asymmetry issues. I ran some tests the 
day before yesterday and encountered a few locking problems. I will 
publish the patch a bit later.

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

[Rafael J. Wysocki]

On Fri, Jan 23, 2026 at 2:20 AM Yaxiong Tian <tianyaxiong@kylinos.cn> 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.

> 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.

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

[Yaxiong Tian]

在 2026/1/24 04:12, Rafael J. Wysocki 写道:
> On Fri, Jan 23, 2026 at 2:20 AM Yaxiong Tian <tianyaxiong@kylinos.cn> 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.

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

[Rafael J. Wysocki]

On Mon, Jan 26, 2026 at 3:15 AM Yaxiong Tian <tianyaxiong@kylinos.cn> wrote:
>
>
> 在 2026/1/24 04:12, Rafael J. Wysocki 写道:
> > On Fri, Jan 23, 2026 at 2:20 AM Yaxiong Tian <tianyaxiong@kylinos.cn> 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.

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@kylinos.cn> wrote:
>>
>> 在 2026/1/24 04:12, Rafael J. Wysocki 写道:
>>> On Fri, Jan 23, 2026 at 2:20 AM Yaxiong Tian <tianyaxiong@kylinos.cn> 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@kylinos.cn/