From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazon11012026.outbound.protection.outlook.com [52.101.53.26]) (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 BDFA43BF660 for ; Tue, 21 Apr 2026 11:22:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.53.26 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776770580; cv=fail; b=dIM4dJOra6LroQZAEWCnAIJpe5+XL9HrTaLaD1ykO+loWYGVwOBf4h15+COvjzI//1MZdyEcTvOOer+XxHEXjM2upGh9OTvpUiOcKmnptPUrjvOFSdlmW0SouveEIORJVDz1HEnpijcx6czfuILJkDNiTPsIfugGak/gCZMnz8w= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776770580; c=relaxed/simple; bh=Q/mbWyJqUgc5YWA8oPyIFVtFZuSrhOI9SoNzInblfBE=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=SETfGggfcslrNW/BHbIPr9j/ZtBS+kIwm8YgEvcXaC2sUHUsDuLEHIqMeC+Ao6m4Ox3Vtf6K1BYlD58H/CeZIffXqMFhaLMxJLAgQEF1JSs8hEToPUO1ejt2ErGNyl9kRjWRlXXdif7SiJaFi++vDSGV08X+PM3P/gGSd7i7RJA= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com; spf=fail smtp.mailfrom=amd.com; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b=GvR2LcMV; arc=fail smtp.client-ip=52.101.53.26 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=amd.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b="GvR2LcMV" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=XExgaiGbd36ORXi1Aeq9g+H/gwyrsGaLPnQ1MTGf+P/aS4/FszMP7P472I8U2zBMQ0a4l2L+rVMKRT3asNq2va6Bs2gqN3fAO+IlH9+8jlOE+UlV0nBsFZcwyN3UH3VYDRv/gFlrjZTkY0ZUx+AP3M8COxuPYhxqldYkL39p/ylo0KEeTHGAvRm15jD8mkbp9w49WlwqB8HTXc190S9W5MTX8KjpUiRvVYWnh5YfqS2tSSAuAkAsjJlv6O45jfIFQV3PZtA0KCu4iAGmY6vFAxRlaD1ecqqsmjbcG0Kp9GjchakODb38Pyf1WCXa/iARiSaVnyYq2to5K0vbvONdhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XllYQVD/lSCb0Rc+N5sVFfQSP3RpxzV/AQEV3uPxtDw=; b=zMPm3MA1hAcB8u0JpP0W6DOlmkWPOyU0xAECiWPycxoDCrvWbPkdoeO4UK1urthBNUoJBwsQf3P5t51JbKp9FBpGDqd8ePnH27Emj8etMSrPa4NlJXAXv+1zcOnddNTQQx4tgdo2jQ3F0S2Ovz6Cnm2cF4u55ZEOay4uv3Qqeu7e8O0jxZEx55pQ3EraVduhLLHOarrGkZz/qo0HaZsywMUo0hwcodIkZgpQEV/T1DY+nGcpqD12NHcpdH6nRF1WEp2gEYs8w5iLWsfl/mMpc34RpaV21nAfF6ewcvrwmxQYdX6bFgaJZ8MxsseG/FnggjNnZ/ZsSiK0L56amfw/HQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=nvidia.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XllYQVD/lSCb0Rc+N5sVFfQSP3RpxzV/AQEV3uPxtDw=; b=GvR2LcMV2CBnTcAdIYVQ8SQaVF4ICHxGp/f8zbVJtUMvOEeFE6X2DzrQmdaZY7Y7n2vrUrY97nbKYCQRNxRUS6cMZ/Lg6tZfkzsxiOkWsXLTBvzOZssmK2mCoH7kXCVZbwEGBBLqKEmuVzzt8QM7y1cvni9+iODawyafmbuzPP0= Received: from BY5PR17CA0044.namprd17.prod.outlook.com (2603:10b6:a03:167::21) by DM6PR12MB4369.namprd12.prod.outlook.com (2603:10b6:5:2a1::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9846.15; Tue, 21 Apr 2026 11:22:54 +0000 Received: from MWH0EPF000C618E.namprd02.prod.outlook.com (2603:10b6:a03:167:cafe::7b) by BY5PR17CA0044.outlook.office365.com (2603:10b6:a03:167::21) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9791.48 via Frontend Transport; Tue, 21 Apr 2026 11:22:54 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Received: from satlexmb07.amd.com (165.204.84.17) by MWH0EPF000C618E.mail.protection.outlook.com (10.167.249.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9791.48 via Frontend Transport; Tue, 21 Apr 2026 11:22:54 +0000 Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 21 Apr 2026 06:22:53 -0500 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 21 Apr 2026 06:22:53 -0500 Received: from [172.31.184.125] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Tue, 21 Apr 2026 06:22:47 -0500 Message-ID: <3cc4d887-f44d-4fe8-a57a-73f595647eab@amd.com> Date: Tue, 21 Apr 2026 16:52:46 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] sched/fair: Prefer fully-idle SMT cores in asym-capacity idle selection To: Andrea Righi CC: Dietmar Eggemann , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , "Steven Rostedt" , Ben Segall , Mel Gorman , Valentin Schneider , Christian Loehle , Koba Ko , Felix Abecassis , Balbir Singh , Shrikanth Hegde , References: <20260403053654.1559142-1-arighi@nvidia.com> <20260403053654.1559142-2-arighi@nvidia.com> <64fe32e0-d428-42bb-beb4-2656d8781b0f@arm.com> <7313ba07-7b87-447c-9c48-2f6b2b53ac94@amd.com> <1230f5df-470a-4e59-8c8e-fa159a6fc093@amd.com> Content-Language: en-US From: K Prateek Nayak In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MWH0EPF000C618E:EE_|DM6PR12MB4369:EE_ X-MS-Office365-Filtering-Correlation-Id: d3739b1c-6a15-43a6-07f0-08de9f9854ed X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700016|376014|7416014|1800799024|56012099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: 6G1DtmtyYnLs8MRDJ/g/dXT3IPNCsTfOnvldzPcQ8CEhBxdfVlaro1wvhdQO9hJKu1RdqLWquIIJsxV6guevI0BCzPgitRN5Z+VSDiDFMw+CauKZ+9ZTvrYehtieApTTgHZKL97YIL9bg8NOZcWHpsvR2MOH5LbMj2IgJxW0pX2gvE+/sHwB4xwzPZAJJts7Hm44oOKaj6ONgPVjdyEVM6zB0hzvnKoZGZNsPHjrCsscq6yptDZIjzoLf4JUBbjSM8Tqb3nsbB+APMyBxMNPkFIcUe+/1CUoIYVG+HSV5l9JYUjuSyafqDE0zfQgWC/iysBRxzP6TaH2LHO6ODKirIuHfo3KjOa8u1ijHDUpjlZYptXeTcZcQFYjp5/Bk3/AZ08sSV4uCE3ZCejO6z13Q2sNWa+70PiEU+KfMGEsmWNgJxHr0v7p9+3rgI0Bu5jHZCubG4/l2NONXN+vD0Pw8mwYLbdxoHiC86i6ATUYAmaB6evcsNiPj0IbPpDuJm96rf0vXGvKNMZ0zz57Tq9Akv/hmnsBn0QPq1AvywTp8zGh1wdB59dlYz3sOsDpgX7pVzMMIYU7xa9bWSkl2CkweFXL55mCPPckTc2GfOBOwskrostPBW1m7LSNbV8i8+xqZtzJCWArH2B3wNTjWRu8jllDybfmgKrDrNzfJ/sR8QoGRc6eBlmzvqXiJkNYpe0gCUIWGXwkprTVeJQCYJVTnIEIhc+dMkYOBzy00fTCvQJVhPjwimXveBsdT1KrzQzo2/ceDh7tROTeFxzWnG+zhw== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700016)(376014)(7416014)(1800799024)(56012099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: WGOfyteJoQU4kgEnR16w0se17FfwaOGbBA31Yqu6iJtWsP8chSP35D4wLFmskC9hM+yVAvtPMhEr+brU090BEplxOq7DM42BrOXfckoaDo7/xN0MAvurPzhfeM4/dsA589As6v5eIebJH7Hhz+63U1xTDY9S9LVBBY8sD4RbiDYh30MrksnMGnPNRYM+hOH1cVmbtwau24SuUbCMCQX3cAQ7gMab9JVOHcIRd7AUueXFo5z0KrWxKP08a5xrFe/wGrO8Awkju+vzOINs+PEuQ2J1sGNk8/k66+D0gv1XW1e9XPqA8lx0a/TsaGlx/iWflm/vpCrXJHuU/RE2ltiXkDrPGS6rVgPqK+i7hcEvcWIRrs2ZWqw2W8kEp/hUXgiTaPCR7UhzILHegNoPfaLUd7QJDu45yGCwm7V6xqnnQt/Wob2s5MYICZEefxruYU7T X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Apr 2026 11:22:54.0517 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d3739b1c-6a15-43a6-07f0-08de9f9854ed X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: MWH0EPF000C618E.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4369 Hello Andrea, On 4/21/2026 3:05 PM, Andrea Righi wrote: > Actually... while preparing the series I realized that in select_idle_capacity() > we may end up clearing the has_idle_cores hint even when the failure is due to > affinity constraints (no fit CPU in the allowed cpumask), not only when no fully > idle core is found in the system and this can lead to false has_idle_cores > hints. This is also the case with select_idle_cpu() but any core turning idle will again reset the indicator so it should be fine for most part where there is a lot of blocking + wakeup. > > At this point I'm wondering if it's better to just ignore the has_idle_cores > hint completely in the smt+asym-cpu-capacity scenario (which would also simplify > the exotic topology cases). > > I did some quick tests with this on Vera and I'm getting pretty much the same > performance results. Opinions? Am I missing something? I don't think so. Generally it is counterproductive to search a lot in a busy system but I guess just making the path SMT aware give a much better result compared to the baseline that it doesn't matter. Can I trouble you to test the SIS_UTIL bailout with your series + the topology changes: diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 78f2d2c4e24f..1356bbdbccd4 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -7990,6 +7990,7 @@ select_idle_capacity(struct task_struct *p, struct sched_domain *sd, int target) int fits, best_fits = 0; int cpu, best_cpu = -1; struct cpumask *cpus; + int nr = INT_MAX; cpus = this_cpu_cpumask_var_ptr(select_rq_mask); cpumask_and(cpus, sched_domain_span(sd), p->cpus_ptr); @@ -7998,10 +7999,30 @@ select_idle_capacity(struct task_struct *p, struct sched_domain *sd, int target) util_min = uclamp_eff_value(p, UCLAMP_MIN); util_max = uclamp_eff_value(p, UCLAMP_MAX); + if (sched_feat(SIS_UTIL) && sd->shared) { + /* + * Increment because !--nr is the condition to stop scan. + * + * Since "sd" is "sd_llc" for target CPU dereferenced in the + * caller, it is safe to directly dereference "sd->shared". + * Topology bits always ensure it assigned for "sd_llc" abd it + * cannot disappear as long as we have a RCU protected + * reference to one the associated "sd" here. + */ + nr = READ_ONCE(sd->shared->nr_idle_scan) + 1; + /* overloaded LLC is unlikely to have idle cpu/core */ + if (nr == 1) + return -1; + } + for_each_cpu_wrap(cpu, cpus, target) { bool preferred_core = !prefers_idle_core || is_core_idle(cpu); unsigned long cpu_cap = capacity_of(cpu); + /* We have found a good enough target. Just use it. */ + if (--nr <= 0 && best_fits == -4) + return best_cpu; + if (!choose_idle_cpu(cpu, p)) continue; --- You can also try "best_fits <= -3" in that last bailout condition and see if that help. -- Thanks and Regards, Prateek