linux-kernel - Re: [PATCH] cpufreq: intel_pstate: Enable asym capacity only when cpu smt is not possible

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <f7b29234-99bc-4fda-8347-b930f83eacda@kylinos.cn>
Date: Thu, 29 Jan 2026 11:34:38 +0800
From: Yaxiong Tian <tianyaxiong@...inos.cn>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: srinivas.pandruvada@...ux.intel.com, lenb@...nel.org,
 viresh.kumar@...aro.org, ricardo.neri-calderon@...ux.intel.com,
 linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cpufreq: intel_pstate: Enable asym capacity only when cpu
 smt is not possible


在 2026/1/29 09:21, Yaxiong Tian 写道:
>
> 在 2026/1/29 05:21, Rafael J. Wysocki 写道:
>> On Wed, Jan 28, 2026 at 4:15 AM Yaxiong Tian <tianyaxiong@...inos.cn> 
>> wrote:
>>> According to the description in the intel_pstate.rst documentation,
>>> Capacity-Aware Scheduling and Energy-Aware Scheduling are only
>>> supported on a hybrid processor without SMT. Previously, the system
>>> used sched_smt_active() for judgment, which is not a strict condition
>>> because users can switch it on or off via /sys at any time.
>>>
>>> This could lead to incorrect driver settings in certain scenarios.
>>>   For example, on a CPU that supports SMT, a user can disable SMT
>>> via the nosmt parameter to enable asym capacity, and then re-enable
>>> SMT via /sys. In such cases, some settings in the driver would no
>>> longer be correct.
>>>
>>> To address this issue, replace sched_smt_active() with 
>>> cpu_smt_possible(),
>>> and only enable asym capacity when cpu smt is not possible.
>>>
>>> Fixes: 929ebc93ccaa ("cpufreq: intel_pstate: Set asymmetric CPU 
>>> capacity on hybrid systems")
>>> Signed-off-by: Yaxiong Tian <tianyaxiong@...inos.cn>
>>> ---
>>>   drivers/cpufreq/intel_pstate.c | 15 +++++++--------
>>>   1 file changed, 7 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/cpufreq/intel_pstate.c 
>>> b/drivers/cpufreq/intel_pstate.c
>>> index ec4abe374573..8105c41861a3 100644
>>> --- a/drivers/cpufreq/intel_pstate.c
>>> +++ b/drivers/cpufreq/intel_pstate.c
>>> @@ -1142,8 +1142,11 @@ static void 
>>> hybrid_refresh_cpu_capacity_scaling(void)
>>>
>>>   static void hybrid_init_cpu_capacity_scaling(bool refresh)
>>>   {
>>> -       /* Bail out if enabling capacity-aware scheduling is 
>>> prohibited. */
>>> -       if (no_cas)
>>> +       /*
>>> +        * Bail out if capacity-aware scheduling is prohibited, or 
>>> if SMT is
>>> +        * possible, as the capacity of SMT threads cannot be 
>>> determined reliably.
>>> +        */
>>> +       if (no_cas || cpu_smt_possible())
>>>                  return;
>>>
>>>          /*
>>> @@ -1156,12 +1159,8 @@ static void 
>>> hybrid_init_cpu_capacity_scaling(bool refresh)
>>>                  return;
>>>          }
>>>
>>> -       /*
>>> -        * On hybrid systems, use asym capacity instead of ITMT, but 
>>> because
>>> -        * the capacity of SMT threads is not deterministic even 
>>> approximately,
>>> -        * do not do that when SMT is in use.
>>> -        */
>>> -       if (hwp_is_hybrid && !sched_smt_active() && 
>>> arch_enable_hybrid_capacity_scale()) {
>> Why don't you replace sched_smt_active() here with cpu_smt_possible()?
>>
>> There's no point calling arch_enable_hybrid_capacity_scale() if the
>> latter is true.
> Because I think cpu_smt_possible() becomes fixed after kernel startup. 
> Placing this check earlier can also prevent calling 
> arch_enable_hybrid_capacity_scale(). Additionally, when users switch 
> the cpufreq driver via /sys/devices/system/cpu/intel_pstate/status, 
> it's unnecessary to proceed with further checks.


Sorry, `cpu_smt_possible()` can also be changed via the `/sys` interface, but only once.

When the CPU supports SMT and SMT is switched to "force", if the user immediately switches the cpufreq driver afterwards, the initialization path will be triggered, which re-executes the relevant initialization. At this point, `cpu_smt_possible()` becomes fixed. If switching is performed again later, the refresh path will be taken and `arch_enable_hybrid_capacity_scale()` will not be called again, to prevent warning messages.

If the CPU does not support SMT from the beginning, `cpu_smt_possible()` is fixed from kernel boot and can also be refreshed without calling `arch_enable_hybrid_capacity_scale()`.

Placing this logic earlier has the advantage of reducing some condition checks when `cpu_smt_possible()` is true.

>>> +       /* On hybrid systems, use asym capacity instead of ITMT */
>>> +       if (hwp_is_hybrid && arch_enable_hybrid_capacity_scale()) {
>>>                  hybrid_refresh_cpu_capacity_scaling();
>>>                  /*
>>>                   * Disabling ITMT causes sched domains to be 
>>> rebuilt to disable asym
>>> --