From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazon11012033.outbound.protection.outlook.com [40.93.195.33]) (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 DBE093E120D for ; Fri, 24 Apr 2026 17:13:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.93.195.33 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777050832; cv=fail; b=DzLfYOXkRM7hIDc4Z0cVzE2kHeICsGYBxHpLIwRqNseWgSqdmRfvmqSK1soxb/6rPhOzJ+duu3HQkyILzarzJxFSM+98kwgWD8mIK9OyvH5N8sLJHvcY6TBF9qd0eGkshujTEWooIWO8bbSQ6xeNc5sdHs4iawhNDd8587wZpdw= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777050832; c=relaxed/simple; bh=V+s/PKMKyWwLIR6kaq3RfASu6vuoc8APQhKR6lWeWcE=; h=Date:From:To:Cc:Subject:Message-ID:References:Content-Type: Content-Disposition:In-Reply-To:MIME-Version; b=dk+kfRD7vVzx3zDqcyoX9guT2C8/igMtEN8WfCgllC/6JTb6T+W1V4eyvQ2BBoB4cld5PNOfo2K9VwnB4/5Io1a1TNI+y3boTLVeby7InJ1A3TEq+4mDZ/MeXcY1w7oiL2esVdERTvQ7Ck1s5Hzrpkd/MAARKGSYAf8k/gzLHQg= 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=UDfjKrW1; arc=fail smtp.client-ip=40.93.195.33 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="UDfjKrW1" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=E5GBgFDYS4Wp8epLxQenHxA1O1QZH4qRdU77WPcrTIy5oSsHo0hOXOalqtDY3JUu4YBl0Pm2rOxCImfEr38wyYggmuryyKN2+tvfXsR1+x1ENEoY6hSjKhvsgPupC3AT0YMgSkm9YsXVoedntXJiZIQ4JcUnp5IK24nGunpjS5+HokjtanB0OG+BkVcqYQZKu9rAWn8saO4hVI1/gehLwfv0jxjLwIRwuMz5mtroEjAELPnvGkzWRTFStXYuxmF5CpoZo1vqMcIkU7A4jvC5ZvvdjVhTQzNv/8B+Q/cIlJZF7p0/TkVxoLQ+/WBTlR4ylUb5KqBElBtSqdkUKLs2gQ== 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=7vihG9nUl/LXG1aRW7sNSzuSPXWvbFyjcOnmBw8Kucs=; b=kOEkmusvp2k5yGkg+mnHSmOudgFCBEaOpZc30DMZyqyZa8vu+NOCIEGzR/JUZ5H2ktOTca7CKMA4TCzn2Puxpqag7lPzkBApF0/qUyHvPGB92ZsGBFV1k983/YPxo7kx93+3th0MVfCtfegDjWKvZ/ogyw6sb55LWB2cD1fJDLyLzCDMSJ2WSW7VGNO2RbjDwR11xEMCVppoZCBq14OWIjLL3tRqOGL2MT+Q6NsL7KJXk5DESCJE06oo21qYPHgYQlh/iKvzY8hBG7DnTdcCMy3+miZic4lG+Gjjj/2EBLr6iUBUpubOKGbs+5Uar3Nu1BPHiKzkD/AWUrDB1Y+zVg== 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=7vihG9nUl/LXG1aRW7sNSzuSPXWvbFyjcOnmBw8Kucs=; b=UDfjKrW1J1NbX0P0AbhlNsOZWYTgiI5kplyGaqOLvH4+WQ0wdXupA1AoelDVMfLQUr1PAGlu0MkdaMAHEtQ05cTdGy+4PxqkMfOHFR0tZoqQa2MxoVlxncv7eQbnSWmTA9nsBkPKCyy9eKbT1p7S3YaYI3ogHbmC8KbDw5YyNoq8OxIqe+LOolddQw0z0BUM/Nar5Bt8lZqzQrqGcxt651fTYKY+Qnmieds0cPUICF40r1xWcE5SAI7KyfjgqgLJLvR10xx/KbPAgLipA6qyXiOtwH9nfkNL5xmQzn45e2hFJrk1KNd/fDmIRG5stCJJqD/pTs/4pQKVVy5+EKqvlQ== 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 IA1PR12MB7709.namprd12.prod.outlook.com (2603:10b6:208:423::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9846.20; Fri, 24 Apr 2026 17:13:45 +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.019; Fri, 24 Apr 2026 17:13:43 +0000 Date: Fri, 24 Apr 2026 19:13:33 +0200 From: Andrea Righi To: Vincent Guittot Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , Christian Loehle , Koba Ko , Felix Abecassis , Balbir Singh , Joel Fernandes , Shrikanth Hegde , linux-kernel@vger.kernel.org Subject: Re: [PATCH 4/5] sched/fair: Add SIS_UTIL support to select_idle_capacity() Message-ID: References: <20260423074135.380390-1-arighi@nvidia.com> <20260423074135.380390-5-arighi@nvidia.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: MI1P293CA0028.ITAP293.PROD.OUTLOOK.COM (2603:10a6:290:3::20) 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_|IA1PR12MB7709:EE_ X-MS-Office365-Filtering-Correlation-Id: ecaf6763-394f-4f46-041c-08dea224d62d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7416014|22082099003|18002099003|56012099003; X-Microsoft-Antispam-Message-Info: JsDKE+GmvuW1mAb4yJ3jQAcuZZ79KfuGik176b/hO6ikrkg0Knlglpy89IDGucZUaPr53xPyxcX2zowzMEFJw93oPMSHRSByrCnvRwkqTNlHvinlYnKXvOe8VzFrLa8PTnUhthRgPOuaiJeQikBq+rbrREGNjorSrZ1/uwj8rPMgPYdjatu36j4dlpayZq21+cMk+dDiADd8fcbfGgTgzJbrW+d5R2IfAtCocka2DcN2AEMGRMttWKq6YF43iAN0meI2Nd6GTtrkK5ZwxQEyh3UJYhChZZ9O6SnGulpl29C6qpF/ocGWFeC4ojqgwbN9YgotYFaV9yNuonr/xFh6fdJECzdPF9e84lYHXMICoe3jx1Og/k7iBBtnUfF3NI13TjQ2VHibBbUoNSPkibqvnAnMY49sOC5lklMZI5dNq2E1ZfqcnlThjacnj9B1ZWCpRd3M603/ZBSQbvebX7iuHph7FDK7/49bftBpXA6UxT3CUcOF7D12o03LayK0IGenVMUoU/3Nef8OzE65T2sMJZi21nVv7tG/aj4NJKFWsbr6eELEW2PC2dVoi/clb4ZvXaG/kaUIPjySbTD8QDFMp4/Puod9lcZki7zIxZeZuvcFju4aVeeuVQP4iV6zuSJV+wttBg5kl5VXGgwykIhtzsYeF0B4PYa696TI8PVeUAMQULTZcv9oNZRrW/rBQXtdJnZ8t/SGiNre6JQDCnHGjcVdOzsf4k5M8wVGUk4Q4bE= 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)(1800799024)(366016)(376014)(7416014)(22082099003)(18002099003)(56012099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?vIITu+xQgIJM0gnKBKE/gGEX9ycO5dcItCuS8btdNA0sI+xjV0sfbQDkFXXl?= =?us-ascii?Q?a4UOkq0XayjrMz5qwKy6xa63Xpg23WhfNtrAhvRrxoF4I6t9ADJo8QzH/2Dv?= =?us-ascii?Q?5OeL7fmU79e1a+t+R5TrYr9DU8I50EPY52zHSs5e66f16toG/N2NEpa7UV9L?= =?us-ascii?Q?B4IC3ruukwPVHxfsgTqJgBF4pSC3DejKbbNW8G2eKslKSgXmKp6RqWmdFChE?= =?us-ascii?Q?krgcpWF/AIeU6onm022JFawTdH0umLqNldNWtYG2nSSRpQ39qukhhQruD6JR?= =?us-ascii?Q?Qt8Ra+dH0Az8RwjlqPiFTvZKZ1RaY2bdqO8VqbbRSxZ3/jnnL3pVRdTw64xe?= =?us-ascii?Q?dUJ4cDu88weDew59cWa6VnirwGAPnOCEKp8tzWi2lot3/1gEZK3CILbihqhA?= =?us-ascii?Q?qQ+twuOJpXfala4SevUQv9NSC/XVferHT6FZtYNWoJGLciszW7KTWZYBkZ/P?= =?us-ascii?Q?wHczX64Hu9A0W1QfhUayGTdeo2IHhjei9R2W6qrqXXbVr4kd1RVxkOuDODqj?= =?us-ascii?Q?qH4DNf1ABaHnsyXCP1O+Cu0sRzIh3TiGuKN79AU66EDhOo1nKPOXLdcZxJyW?= =?us-ascii?Q?LxsMltmceDYJSvr3jBVbESN9BobMaSjgD74NvS/cwcXCdthCoIstOkltSmZU?= =?us-ascii?Q?g9KGpRt7CSEdSwW6QJJ+DHPanIfcHGSGwOhrGbPn8kCBt1HYWY88lu5oUKz5?= =?us-ascii?Q?RrClPonQOKG8UhkaePdjd3ZgZj7YJP4Yz1I4390tK0p90Hn0Rtscwey8koMz?= =?us-ascii?Q?nIdgKBaiWR7lcCNau7F0FdvrYB8uLxaCTicoKV3zDuvnLExuxpKec1MeKclM?= =?us-ascii?Q?1wDbeJAJiEJXQSxqDDxvvVcGZQ4YvylTCp+VsvlWinnPXM4VbyVEHKBkLQ7h?= =?us-ascii?Q?Fl1qh0baTuPuzvgZRUoZ/ZUtP8ptAXQehgj5Tb8jUR1OdYhQXQRocG7AJYe9?= =?us-ascii?Q?Xn+nNpH9KTZZ3Arbq1RY1F5LkYhtWlgo92uC+RQ/n0dRdKlmaV8ez4EZ2UK2?= =?us-ascii?Q?hNXoQf0avatVGzC9xmoAfN7B0Cp6Z7J77jPMYvphH0ilRZW1pTQKuDHSPQZ4?= =?us-ascii?Q?txBHccVAAMMWu/WgvJRV+sGF03gFdIfpxyrhwsE3dCm6rWXjdmZvgnOg6RNa?= =?us-ascii?Q?Fn3nItbOoh7HntBeTPBwtgVdLa11suhlEu2o6EiUVh4TkU25BIEAYpmM1oBx?= =?us-ascii?Q?n1MGF23yfA1vTsLwuDET3lldo2Eu0ZeWtUXuWvw3j8y0X3EaJiRJ14aFPx3S?= =?us-ascii?Q?A6xszh8kl871ilxg1C/TJCFSGwOVvOejSUwRvHX4G6KQ0wZRBUGYQ4NHWEuc?= =?us-ascii?Q?OHQcy7ktw4VXkTnQ0nqjjqVaHrrXAoy5EWgDvNzJMkRGjMbf4WLX1XnYNpgk?= =?us-ascii?Q?4NLIZVbHyd2OWoI7V6Z3RvgFMjpqDoHW4aI5lRsCffMde4NV9qY03DOcQPrA?= =?us-ascii?Q?Z14hi8QEJX6PgQ15Faah1XuM9vMXcu8fXtcUMCSaCOyPn7JaZz5Z661HuUpn?= =?us-ascii?Q?9kb0Y5OH0lu6yinIxgdL6+8G5MHN50mUUrd/Bs2zegn3yNlwyCkuLuw0WisW?= =?us-ascii?Q?K9NzxahCDqLQ2G1Mo6BlIsZJnu9/Nu6P11SCEhA3lNBT98XMH0lyQDANlXZ4?= =?us-ascii?Q?f+7ajBCFrpKSyoH2shSdtjlUjviy6oM6b8Sqy1anriNZ/uYgASm+FfG9Htzz?= =?us-ascii?Q?csmrW4cI9olp1sNQeZ9KJZI9owJcrWDhVOiu0OrAcfOv3mS8DLcZy4v5pgxw?= =?us-ascii?Q?nJsk2+zldQ=3D=3D?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: ecaf6763-394f-4f46-041c-08dea224d62d X-MS-Exchange-CrossTenant-AuthSource: LV8PR12MB9620.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Apr 2026 17:13:43.1176 (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: WenB3KyhMLK6wqpjCpMTiLD+EkleNoNajA+6WuVo7Qxrts4KXVPn6rkQRGUIQQqrjwa3vfijQqokV7zuYG0Hgw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB7709 Hi Vincent, On Fri, Apr 24, 2026 at 02:32:30PM +0200, Vincent Guittot wrote: > On Thu, 23 Apr 2026 at 09:42, Andrea Righi wrote: > > > > From: K Prateek Nayak > > > > Add to select_idle_capacity() the same SIS_UTIL-controlled idle-scan > > mechanism, already used by select_idle_cpu(): when sched_feat(SIS_UTIL) > > is enabled and the LLC domain has sched_domain_shared data, derive the > > per-attempt scan limit from sd->shared->nr_idle_scan. > > > > That bounds the walk on large LLCs and allows an early return once the > > scan limit is reached, if we already picked a sufficiently strong > > idle-core candidate (best_fits == -4). > > > > Signed-off-by: K Prateek Nayak > > --- > > kernel/sched/fair.c | 21 +++++++++++++++++++++ > > 1 file changed, 21 insertions(+) > > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > index 9bd9dc6e0882e..6b67049f04c3e 100644 > > --- a/kernel/sched/fair.c > > +++ b/kernel/sched/fair.c > > @@ -8002,6 +8002,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); > > @@ -8010,10 +8011,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" and 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; > > The comment below applies to select_idle_cpu but we want same behavior > for both function > If test_idle_cores is true we will not look for it whereas we don't > care about nr value when test_idle_core is true in the > for_each_cpu_wrap loop > > > > + } > > + > > 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; > > In select_idle_cpu(), we return immediatly when nr == 0 and > test_idle_cores is false but we loop on all cpus if test_idle_cores is > true until we found an idle core. In the case of > select_idle_capacity(), I agree that util_fits_cpu() add another level > but shouldn't we continue to loop even if we found a best_fits == -4 > Agreed that we should keep the behavior consistent between select_idle_cpu() and select_idle_capacity(). I ran some quick tests with nr / early return matching select_idle_cpu() (using the SIS_UTIL scan cap only with !prefers_idle_core). So far, I'm not seeing any noticeable performance difference on my side, so that looks fine to me. Thanks, -Andrea