From nobody Mon Feb 9 12:54:34 2026 Received: from mailgw.kylinos.cn (mailgw.kylinos.cn [124.126.103.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EEFDB30BB8E; Wed, 28 Jan 2026 03:15:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=124.126.103.232 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769570136; cv=none; b=KjO6VlPQqMeHNyXYfBksR6qdVUdsk9C5tgJpZ3i7/BpFoCE7D1+rmMp9xaY3RWyXO8ZFAkRa/BiMcY4Tpqx0gK4pVfY10vn5AkUcckZnrTwRmXCXQ7dHzEQNTN+/rO9Dl+JlRCDdISfFLlz1TfTjMfmYzSIc7+55kASpixvttfM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769570136; c=relaxed/simple; bh=ZQUtcrYF+pBFHQqnro5+m8v+5kSVopBoz5sC788DA4Q=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=Y+GNvFaD1X18VM2NyF0/STaQZ+7CjnUlhDr1DcZg3wqQicaUHSmWSQqeE/tBCCj1fiQJ1Q255GR/twO7W+gVlg9KEGe1f9czjiX0ZTBwgAKSqa/0UgGz1FhogpHPdNREQgIBNWoH7rP+hvybpdci8QaFhnL54Xcr4/EqftWaptQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kylinos.cn; spf=pass smtp.mailfrom=kylinos.cn; arc=none smtp.client-ip=124.126.103.232 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kylinos.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kylinos.cn X-UUID: 978edc62fbf711f0b0f03b4cfa9209d1-20260128 X-CTIC-Tags: HR_CC_COUNT, HR_CC_DOMAIN_COUNT, HR_CC_NAME, HR_CC_NO_NAME, HR_CTE_8B HR_CTT_MISS, HR_DATE_H, HR_DATE_WKD, HR_DATE_ZONE, HR_FROM_NAME HR_SJ_LANG, HR_SJ_LEN, HR_SJ_LETTER, HR_SJ_NOR_SYM, HR_SJ_PHRASE HR_SJ_PHRASE_LEN, HR_SJ_WS, HR_TO_COUNT, HR_TO_DOMAIN_COUNT, HR_TO_NO_NAME IP_UNTRUSTED, SRC_UNTRUSTED, IP_UNFAMILIAR, SRC_UNFAMILIAR, DN_TRUSTED SRC_TRUSTED, SA_TRUSTED, SA_EXISTED, SN_TRUSTED, SN_EXISTED SPF_NOPASS, DKIM_NOPASS, DMARC_NOPASS X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.3.6,REQID:df37e059-f674-4079-a3ae-1da15038eede,IP:10,U RL:0,TC:0,Content:0,EDM:0,RT:0,SF:-5,FILE:0,BULK:0,RULE:Release_Ham,ACTION :release,TS:5 X-CID-INFO: VERSION:1.3.6,REQID:df37e059-f674-4079-a3ae-1da15038eede,IP:10,URL :0,TC:0,Content:0,EDM:0,RT:0,SF:-5,FILE:0,BULK:0,RULE:Release_Ham,ACTION:r elease,TS:5 X-CID-META: VersionHash:a9d874c,CLOUDID:1f7996e726c7aea7f500e9a525b82510,BulkI D:260128111528992RBOHJ,BulkQuantity:0,Recheck:0,SF:17|19|38|66|78|102|127| 850|898,TC:nil,Content:0|15|50,EDM:-3,IP:-2,URL:0,File:nil,RT:nil,Bulk:nil ,QS:nil,BEC:nil,COL:0,OSI:0,OSA:0,AV:0,LES:1,SPR:NO,DKR:0,DKP:0,BRR:0,BRE: 0,ARC:0 X-CID-BVR: 2,SSN|SDN X-CID-BAS: 2,SSN|SDN,0,_ X-CID-FACTOR: TF_CID_SPAM_FAS,TF_CID_SPAM_FSD,TF_CID_SPAM_SNR X-CID-RHF: D41D8CD98F00B204E9800998ECF8427E X-UUID: 978edc62fbf711f0b0f03b4cfa9209d1-20260128 X-User: tianyaxiong@kylinos.cn Received: from localhost.localdomain [(175.2.149.138)] by mailgw.kylinos.cn (envelope-from ) (Generic MTA) with ESMTP id 1839394592; Wed, 28 Jan 2026 11:15:26 +0800 From: Yaxiong Tian To: rafael@kernel.org, srinivas.pandruvada@linux.intel.com, lenb@kernel.org, viresh.kumar@linaro.org, ricardo.neri-calderon@linux.intel.com Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Yaxiong Tian Subject: [PATCH] cpufreq: intel_pstate: Enable asym capacity only when cpu smt is not possible Date: Wed, 28 Jan 2026 11:15:21 +0800 Message-Id: <20260128031521.389765-1-tianyaxiong@kylinos.cn> X-Mailer: git-send-email 2.25.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 --- 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) =20 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; =20 /* @@ -1156,12 +1159,8 @@ static void hybrid_init_cpu_capacity_scaling(bool re= fresh) return; } =20 - /* - * 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_s= cale()) { + /* 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 --=20 2.25.1