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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJZ5v0g8xM62_882WP8__x_RjCN_yeLUg=itXVTXsL=0T_mUsw@mail.gmail.com>
Date: Wed, 28 Jan 2026 22:21:03 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Yaxiong Tian <tianyaxiong@...inos.cn>
Cc: rafael@...nel.org, 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

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.

> +       /* 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
> --