From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from DM5PR21CU001.outbound.protection.outlook.com (mail-centralusazon11011006.outbound.protection.outlook.com [52.101.62.6]) (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 18FDE25D1E9 for ; Sat, 18 Apr 2026 08:24:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.62.6 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776500656; cv=fail; b=ficCTsphDuNmzJ9QWzemjMgcRUC56pxzORLP3FKApZ2qIy9UKgxIt0r9ZesO9/nG8NVDJZP7MsYNaF7DAH6lN1uW9V1MPt/umlZo52UC1T6VFDoSjen4aSGbKv0PsLC6f9SMWstaUQLG3+DDpV+mJqfzLlEJhjoAmIRqxS5cHJI= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776500656; c=relaxed/simple; bh=xFn/wDDMbp6/jl2Ii6qy/PgwfMXYzGX4fB/nscv6gtc=; h=Date:From:To:Cc:Subject:Message-ID:References:Content-Type: Content-Disposition:In-Reply-To:MIME-Version; b=depG+mCqdDiNH1RvgERu27/LTr1qOKjVg78ABzHnkdOmXwdPTJVndAPS72wV4wWGkmsVpHw/PeK7COPqLIf1u9yvtfVp77shUpBDVJ/pDV3vio3QV5WBvL+3HUKD5HkFKa9/hIyzicl4amVO5zRIDVwYyNztYMQPU+yWcmWZyX8= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=nvidia.com; spf=fail smtp.mailfrom=nvidia.com; dkim=pass (2048-bit key) header.d=Nvidia.com header.i=@Nvidia.com header.b=XuvKfAyb; arc=fail smtp.client-ip=52.101.62.6 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=nvidia.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=nvidia.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=Nvidia.com header.i=@Nvidia.com header.b="XuvKfAyb" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=WMY5zQQTKHIi5BxwW2DcEmSQvvE9pEXNHcjelQHGvTqyPKeUYEOzCuIhSN9BgQ7DumkDxCvPK5T8+MyfJeuLJzMKqUKxsHCUs0mAEYNYqR19rRwwCtKCYvH3XWhELZY3I9fcEBqgAw3+NQFb3R0qFSWbAOJTsVWpTMgQRv/vFxs1JlVSrhThgn8ds4zRRX6DevwWXNfQBfoEpLZKQ1dX3BcAwM2mmyd1YGo5LtpTiosxJRfhYm4V5NnGL9zAZZbmjXXphxrqvX73kqT08gFKAumIzPS08J/ywOg+6nZSW/DFwAI5vKsCfw7QJCDz11mxtTryVdkPDRAz3ut+FJXglg== 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=KTZqZn1pU90kCv9Fhe9dldmMRUzw0PQYSuH3cP8YKTY=; b=V3SCGieaaOmq02ZvMuqsU9Ax9ZQ0UKJePNvRFdEop29+qsI8svXFfKpdyvx2nhULlkCp5e90eVg0JA0rBUZPbsSrTz+m93g5Itp1ZoekiptFXVvU+LyObQ93xjU0oUAQzQqJE/xI0Y5wDHTsnGB+FqkvroeWSlRp3tJmmqmuIemhuksZ7xJukuHMNT0gKl4hl0vqJaISUr4vFsXXsS2Q0881ToW0ytm5dyBV9UH97m1mRP54BKgoMw4EBKl/SJWJ9xxzohPPZWV71nrpuBWF8q0BjUav/Lps23/jzoBfscpU72Sf1ic4UGLn6lfNgWTfiKiW/dXK+bbfv58zaD2g5w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KTZqZn1pU90kCv9Fhe9dldmMRUzw0PQYSuH3cP8YKTY=; b=XuvKfAybq0ILvi8PZWA7r0XZvOLykkrZ2GqyQ2IAgn9gWwjOu6KJwyGGUV2pgdfcnla4XKeuUnyhabkYOpnjiD7QkoczEpeSUFGikeeaReeY0ed8YsIxaNTCS2CMSDEKa9TQK4wiX5/+vLSziFB/g4m2c+XNA9/V3RbVq2q28SxgpKm/7sybhHtaJxIxbl3MRjHu5mkq9wnbsiHQlq8V1OlneGYQNFvnu/DZIrmZjb+lQhHe6xskxfJksi77gMfsIjZkh+uh6tcl68lBLjhj45z3aXsBnyBy6xqgGpodfiwKtK87zQ6CnJUBQTokUsHD+z/cRhseECe+OMjKgxOrfQ== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; Received: from LV8PR12MB9620.namprd12.prod.outlook.com (2603:10b6:408:2a1::19) by SA0PR12MB4400.namprd12.prod.outlook.com (2603:10b6:806:95::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9818.21; Sat, 18 Apr 2026 08:24:11 +0000 Received: from LV8PR12MB9620.namprd12.prod.outlook.com ([fe80::299d:f5e0:3550:1528]) by LV8PR12MB9620.namprd12.prod.outlook.com ([fe80::299d:f5e0:3550:1528%5]) with mapi id 15.20.9846.011; Sat, 18 Apr 2026 08:24:11 +0000 Date: Sat, 18 Apr 2026 10:24:01 +0200 From: Andrea Righi To: Dietmar Eggemann Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , Christian Loehle , Koba Ko , Felix Abecassis , Balbir Singh , Shrikanth Hegde , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] sched/fair: Prefer fully-idle SMT cores in asym-capacity idle selection Message-ID: References: <20260403053654.1559142-1-arighi@nvidia.com> <20260403053654.1559142-2-arighi@nvidia.com> <64fe32e0-d428-42bb-beb4-2656d8781b0f@arm.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <64fe32e0-d428-42bb-beb4-2656d8781b0f@arm.com> X-ClientProxiedBy: MI1PEPF000008CF.ITAP293.PROD.OUTLOOK.COM (2603:10a6:298:1::42c) To LV8PR12MB9620.namprd12.prod.outlook.com (2603:10b6:408:2a1::19) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LV8PR12MB9620:EE_|SA0PR12MB4400:EE_ X-MS-Office365-Filtering-Correlation-Id: a4382944-9e2a-412f-e94c-08de9d23ddc9 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7416014|56012099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: ubwkgfhFAQxSONPuZWHKjxJ1jaEQNNBomKZ81o1alYfHEwNDO8L0oadrjQa0LO7bzjvj+t1hXcYRX2WwTJ653sOv0Vm+fyHOsY4Vk0+jCSFQYTUThJIDz0p3WpvH984I0/U0ZG76PKxIYaP17UIpwF5+8CFhICy4uaQCwUCglxX++0THCmIyoEt/zLRxOLv+D4WIRP7NsahUecM4/ams0RTsk5hC+yb3Ucid6k775EbVlI5qd6/5Kg7kEZN68jsTddt8ELZCyk1h8G62vAEGg2sa+EMwR541BmQ5ow1oCGT4x18EPFTLEoqODwwa6FMuK7CyuYO2tdlVyAtVAEVyMyHQI6Ls+DmaMkbn9FwNgGJth8A4WUYAh3uRf6plYi3ioHDkjcuRHEudReLxQeI1rlcJk0J+yq/bI5GjExu+2irgl12ev0KZyvXr1i8yi/8DcrHLi0kCsJHCoZzr1jpbuyIfLhO2AQyfzNGV4/4jbz2c3NOYhnqoI/LPnvH+jVfsxLqoXppRp4f66LtskrpfGZU4setiNKvwxnU3wcxJL5ITtsXmG6udu4dGBUBRPejcqtDpal76gNxOnO1/wNM2QQ7EOtqsRNKgkhJj+DeSVAUlQwGXftqMXoitOUVM/PEkmqvwK96dohRMjYDBvdCFYBQq6v8GrVw3CgsOTIOi92/zy8iof45dkNbRQsuTuCm+Rv39ZA+x24VH6+PRQZwe2C7bEtlI1BWVuhewTeuXNu8= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV8PR12MB9620.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7416014)(56012099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?riEi11RM71c8o35XU9qxMGbPpW4dvohuGGqU5YqxB5MYDNgogrwBIj+YSTva?= =?us-ascii?Q?11iL/i//HvgG3aOXvU254PBW3+ljEvV8u7klt4bNcVlmkqZNdfmXa17IEQnM?= =?us-ascii?Q?tg/fdK/hf5Hd5o9vgDMxe00L0EZGmqhTVDxmni4C8pbeXv/JYD6F6u3aZFMl?= =?us-ascii?Q?nNPoCDqtSynN3vA8QYAb2d3O0r8P+xoRLlEOt4Gbw8FENW2UVMLyqVLoJdDi?= =?us-ascii?Q?g51uLThYoxQxBVMm1j0Am0qHna/waC/IVG+0X++jidse1GJCaXHqi8sd11wO?= =?us-ascii?Q?FWgJa/vGvBYOWA/q4sr6qqODR82v1B+YxocNCTeug+EtmxvyBTMmy+5MnkKj?= =?us-ascii?Q?c45uU1jskDyW+OYY9e87m/iuy/gBWajVA4DnzE0W+Yl+zxbieJQjR+Sskxm3?= =?us-ascii?Q?Rnbyk+VmlKDqTr2fRoNR8no5BPT2EZwIwcEbJ0Ax1RFDpxi5hQpAokb01QKW?= =?us-ascii?Q?xFDM56ayLdJ3QLG/SpP7D+QJEFCRPaCxxSBdNL+Ey6QxnwCqoFtIakL/THTa?= =?us-ascii?Q?C4ZVzJYEDNnrMKUNrtWVbAfdzsrYlPKG1AuHqHQnSp8WkCsUpZrJz4/xPSxw?= =?us-ascii?Q?DIqZV7tN/H10mQyysrPQI1/bJfDb7LfTzuewIpP2U1wMuqkoHeGXKTk0B/aD?= =?us-ascii?Q?T7EMa3BGcy7wc3FY+oDqR1rRTmqnEs6RhJI8SYkODH2Zo8ZpcR/Mw65/ygUb?= =?us-ascii?Q?Ej+gEGN8H/XDfKsCK7prPVKGQHRaPu5TDgkJzxYZzCRa+4lUpDPQU6rtyeKK?= =?us-ascii?Q?hKCjE2Y65s7D97CB+6e28+MVuSN8rVZIlCToXHhKyIyLNoxdY8s4MssVGJ2Y?= =?us-ascii?Q?kevapyCZQ9micHNR/lVbSMSJ21cY6S6ZfNvVtqwnRpXcmgXxdoGffl6BbZuy?= =?us-ascii?Q?K3COUSVZWymOdC2HXugtR67+hz1+nd46F8yUdxhAP5FqheUJtHNNtoS91yM8?= =?us-ascii?Q?+rmroX/V5dYqtDH2ceB9zHQZmuMVc3sn/97xbtKKmpizTuTBGuiGzbzN3F7c?= =?us-ascii?Q?wIXs9BX3F6pwaYMl6H2rvVviojGY3p37qH44JFv2foZv0tEF/uW/Cd5fg8FF?= =?us-ascii?Q?SOt1jUUtJn7/kKR4WKgbkMXA0e7Hfg8KV/rrmLj6usJMZVksXNrGcgjhW0kY?= =?us-ascii?Q?F10j7QhTNuOCF6CLgLqFnQrjJ+VlKtKeovS0cTww4HBiuwSWfEEQeYoLYHrO?= =?us-ascii?Q?4GLj2yEzp1UMxG4kw/Ml5vNDGJSbfyxuT/18MTy3t4g/vkRrg+SzJNA40dZG?= =?us-ascii?Q?tK9Gsay97nglCbZD8d8Bb2LJlfD+HEbEtzPjamShlfwtFpyGOw6U2pk4wojo?= =?us-ascii?Q?60pEKcOyDPDIoZmlG7rvq+XFwLDPk/2wzwLk1iaP+2R6cHafZTBWNKJ/taVu?= =?us-ascii?Q?xYGY9e6EpmEJw9i9GAR0SvWYF8JdvBvbg/fIRuAAGRu+PM1SMnYNbfg4fKhr?= =?us-ascii?Q?PEgnehpjXgq2KwzK+w8rfQPlEdv5xQzZqi1B1FV8SftFh2AjBvzgpuQ0SjvS?= =?us-ascii?Q?R4GKOEj2aQMOno9M1cJJpiHeDP+r40jRVzzs6MQQ7px4oSsQXJoxFmlv+XUK?= =?us-ascii?Q?fxbyDJ2AjE0cjKlimYZ6pwiOdXHgaLhLvMb/RcbdM57pHDEFt1UlQWcYYs/l?= =?us-ascii?Q?vCZTQNHN4OTx1KCqPr0dZho7qHYAl/Uk0ycEPKFU8Au2/OFlFuH0RsQysSZn?= =?us-ascii?Q?Ec1j2AM4s7PrbQMngUWPj8r/tPGjOGNHlegbvxeZLzd25dvOBN880L9dyrrH?= =?us-ascii?Q?VgTeVxb9wQ=3D=3D?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: a4382944-9e2a-412f-e94c-08de9d23ddc9 X-MS-Exchange-CrossTenant-AuthSource: LV8PR12MB9620.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Apr 2026 08:24:11.1833 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: febjxmzog6MryuTP8szApbvlForjciCo+K+kp/Oos2FlDLuwIfaUPtzSFrdPG8IArbcRdZm2vagsMIZwMRhP6w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB4400 Hi Dietmar, On Tue, Apr 07, 2026 at 01:21:16PM +0200, Dietmar Eggemann wrote: > > > On 03.04.26 07:31, Andrea Righi wrote: > > On systems with asymmetric CPU capacity (e.g., ACPI/CPPC reporting > > different per-core frequencies), the wakeup path uses > > select_idle_capacity() and prioritizes idle CPUs with higher capacity > > for better task placement. > > > > However, when those CPUs belong to SMT cores, their effective capacity > > can be much lower than the nominal capacity when the sibling thread is > > busy: SMT siblings compete for shared resources, so a "high capacity" > > CPU that is idle but whose sibling is busy does not deliver its full > > capacity. This effective capacity reduction cannot be modeled by the > > static capacity value alone. > > > > When SMT is active, teach asym-capacity idle selection to treat a > > logical CPU as a weaker target if its physical core is only partially > > idle: select_idle_capacity() no longer returns on the first idle CPU > > whose static capacity fits the task when that CPU still has a busy > > sibling, it keeps scanning for an idle CPU on a fully-idle core and only > > if none qualify does it fall back to partially-idle cores, using shifted > > fit scores so fully-idle cores win ties; asym_fits_cpu() applies the > > same fully-idle core requirement when asym capacity and SMT are both > > active. > > > > This improves task placement, since partially-idle SMT siblings deliver > > less than their nominal capacity. Favoring fully idle cores, when > > available, can significantly enhance both throughput and wakeup latency > > on systems with both SMT and CPU asymmetry. > > > > No functional changes on systems with only asymmetric CPUs or only SMT. > > > > Cc: K Prateek Nayak > > Cc: Vincent Guittot > > Cc: Dietmar Eggemann > > Cc: Christian Loehle > > Cc: Koba Ko > > Reported-by: Felix Abecassis > > Signed-off-by: Andrea Righi > > --- > > kernel/sched/fair.c | 36 ++++++++++++++++++++++++++++++++---- > > 1 file changed, 32 insertions(+), 4 deletions(-) > > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > index bf948db905ed1..7f09191014d18 100644 > > --- a/kernel/sched/fair.c > > +++ b/kernel/sched/fair.c > > @@ -7774,6 +7774,7 @@ static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, bool > > static int > > select_idle_capacity(struct task_struct *p, struct sched_domain *sd, int target) > > { > > + bool prefers_idle_core = sched_smt_active() && test_idle_cores(target); > > Somehow I miss a: > > if (prefers_idle_core) > set_idle_cores(target, false) > > The one in select_idle_sibling() -> select_idle_cpu() isn't executed > anymore in with ASYM_CPUCAPACITY. > Right, we need to add this as also pointed by Vincent. > > Another thing is that sic() iterates over CPUs sd_asym_cpucapacity > whereas the idle core thing lives in sd_llc/sd_llc_shared. Both sd's are > probably th same on your system. Hm... they're the same on my machine, but if they're different, clearing has_idle_cores here is not right and it might lead to false positives. We should only clear it only when both domains span the same CPUs (or just check if sd_asym_cpucapacity and sd_llc are the same). However, if they're not the same, I'm not sure exactly what we should do... maybe ignore has_idle_cores and always do the scan for now? Thanks, -Andrea