From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from DM5PR21CU001.outbound.protection.outlook.com (mail-centralusazon11011001.outbound.protection.outlook.com [52.101.62.1]) (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 A726128CF5D for ; Fri, 31 Jul 2026 14:02:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.62.1 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785506537; cv=fail; b=RUe+uah+isLf1UDK709aWKFwNX+B2Cy0XQdHE/cqdeoYj5DK8EMKRG2OrDpk/aF/zd5ISUkB5Hq7pUvtHOVSq9iN4rpOie9FdOXCPNE/UtS+5ngEzeqRJc2b7b74FdMlSPNlFVLcMoUjFrnRWvBoP/T5AJ0T64C1uAnQOEyiDBk= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785506537; c=relaxed/simple; bh=hYWA880XG6+ZnaKEH7UCM8CNiIvZYClvkWRr+maPg68=; h=Date:From:To:Cc:Subject:Message-ID:References:Content-Type: Content-Disposition:In-Reply-To:MIME-Version; b=nzjht1ouoX7yGK6SJrS8pLyeVEQWFqe+AY9D+Co1iS49i5K2HKFmSfb3vcPyKeXXn/EjJxI4w1k3droIgJD7xnua92OOmKlpmgpjaMBUJqa/cvfLhqOZ/q9W+W8HL4eXXX2HqsUS9YnXsuNKBVpG9ZmnP5gxt9933RZl4woAJG8= 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=TwJjpLR1; arc=fail smtp.client-ip=52.101.62.1 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="TwJjpLR1" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=p6QLAseDLVjyrm9pDpz7OVuR4AMVXT9jDmf/cim4bRIz9mPAZw1SUEb3RjjSOEPhwjm74hnQgrwJfbTSIKJnXsV/sVFaagWa7GgdB21XtIhOUy6HiIHiJvbPvuiuEEw6SaogMkBEDAtpWJ0IcS1Yxy5C1QppJZ3BqFGH6R8af0lOkzaA5LQ5RsLoMWs3MdwW/U2dwRmq/lxjb9S88ZUkpGwb2kEcEKo/cFNlENIv+ecRWkWigCf30+ETyqcERO3/3g1eF4Z16y+khRAarK8xRL4W3frMo0iI276NHY6ccGnlq/uKxcXphWo3LrtnVp0+IfgPck3PRZGwCpFLahpeVA== 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=YTs0feByUc0Gx+0eQ/vuafetjC3x/Ris/m/YdK/sGX4=; b=RS016Y062IXe3iNywrupSwAC0VHquiDTbyvRDmeqeYuhWxO++aLz3dhFe2DCX+qrmsCV2QKz2jOrKxitc5W7a9aQIa/L1Q7JPnMcRnVQMU1Hacf+7EUQvDBunfoeUoi1CBIsr80kNCPXJw2AKMXE2nDTt3dmDev4ag35EuYDdKc5570IYIHF3HRhsQJijeH7da5tM7G/fgdsbRzq6mHA6rVlCDRRNziKfAyNm8p0zEnPoecVOoyy9KJid48WkI7nahMUwn4l4shu10oO3fRPUDkZBaj9DFIMLDIyQpcyU1803C3a3+0m2gkWJU66mfPPLFA+QOWUDNipq/eFRaPnaw== 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=YTs0feByUc0Gx+0eQ/vuafetjC3x/Ris/m/YdK/sGX4=; b=TwJjpLR1fbCnffAAX8U4pLPAFbcwgoMu2uV8HxM1aI4INSe/51Zq8G+/qxb5aRcACw5VKph37nFfD9Vqel3BMNLpUTnZTsLGTl0XMZ4+o8ufJQvuKwh/mQnPynhYkSlSWmvOPAHeEr7V4FZBcgjyw4bTjBeeXJM9E84DrApbLgOwahIOoszUCLI6UQUT7WRpfvzCl2KXIsJbYMrQeaZUOBWgCL3wV+7uWZ24d+GalBcY7v9F5v5NFxZLmnA2wao9rlm6vDyJ5ddymyXusm/hzgFd1SfukvUI7AXC3wxAAz7ynCie4FcS1bp9cyiFTt7W9H7/2Ufma4Y7FXyGpKF9xQ== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; Received: from DM6PR12MB4827.namprd12.prod.outlook.com (2603:10b6:5:1d6::14) by IA1PR12MB7661.namprd12.prod.outlook.com (2603:10b6:208:426::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.270.15; Fri, 31 Jul 2026 14:02:09 +0000 Received: from DM6PR12MB4827.namprd12.prod.outlook.com ([fe80::6261:3040:864b:159c]) by DM6PR12MB4827.namprd12.prod.outlook.com ([fe80::6261:3040:864b:159c%5]) with mapi id 15.21.0270.015; Fri, 31 Jul 2026 14:02:09 +0000 Date: Fri, 31 Jul 2026 16:01:59 +0200 From: Andrea Righi To: Mete Durlu Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , Christian Loehle , Shrikanth Hegde , Phil Auld , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] sched/fair: Prefer fully idle cores for NOHZ balancing Message-ID: References: <20260729163225.1987068-1-arighi@nvidia.com> <45048fc9-119c-4770-a1d6-ab2b7e8f2a9e@linux.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45048fc9-119c-4770-a1d6-ab2b7e8f2a9e@linux.ibm.com> X-ClientProxiedBy: MI3PEPF00004EAA.ITAP293.PROD.OUTLOOK.COM (2603:10a6:298:1::44e) To DM6PR12MB4827.namprd12.prod.outlook.com (2603:10b6:5:1d6::14) 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: DM6PR12MB4827:EE_|IA1PR12MB7661:EE_ X-MS-Office365-Filtering-Correlation-Id: eb633827-9363-4668-3549-08deef0c500b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|1800799024|366016|23010399003|10067099003|4143699003|11063799006|56012099006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: RMVLCVTctimDUHkcUjOlHHIs1Z1Z4TR4nLzr10DOlbdtwHCz7J3AAKDKtT7coGSvrNb0fHpfYXc7VgGT6dxFzFw5wGDuPVqeLu5hTjaO0pqkDGO2pnxWV4rdTn7ITjkiGYgj30Vm16LKW15/L2QwtuGavzy2PXqL4mYfiS6P3mWXxhtXyn3F87rCrlncorWstoOa4BPvKeqNQz3LtFQPL1pI8mUZ7OcBoJnQYTmoQLNDpnaZK9MQJ/wL+pLOG1FTuhfFEZAA0Eb9wpwNo7Mc+Y1DdIv1+PhYgNibe5Q/jmKPvo0KiuMmyhhLzufRt3pZzTHxOmjsAib5dy9boCQGIdX88qgIngW8eNuH2t5+JXSIHMrpft8lGMTlkD3B9bOa9SWe6KOlXHdWi4bndOxRCdIaUiA0p2d7YbZ+sjjTBsSJtd2UHsyTO2hZZiDbiT2wRfzMJdZp9CGrrmj/ZhZrHsPmg7GIQpsI4avs+uVQ73k3kYR3l9EZeCfY1uhK17BjIWMzYZcQ+q7duuSPgzbalRhphg6tWmBef3bLvpXRn0Snwr+oUePe+UpMnSN8uNDZ70YhF1h/HBnHJnkRnwxppTrh87DyeWbkw6fBlM5qmmKc06dy7P+f+lMSMO22hYF+Trd0EQW81DJewHqBjftAaKMyvkXv1sdvzQMaPy6mQcE= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR12MB4827.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(366016)(23010399003)(10067099003)(4143699003)(11063799006)(56012099006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?UVeOAntCL1V4TQsLgsSi5SSFOzwKo8EY7NT9VcOJElWdB1ipAs+7Nm9N1Vc/?= =?us-ascii?Q?tcHrZYBJC1sByPXXouITqPJvm0LDd6QCcPQA9VkfROw1ybCEpej+f/HXe4TD?= =?us-ascii?Q?87dqxkjfZ/O8d8EMgEzxnVjgBWHNhLSh1VA6pcSW4MMjOTZF3dYhLBOzISgu?= =?us-ascii?Q?FILrdhRptMomMIZEXMPXu0x5Pb4XW2bHHc5hsdnCVhHrrqGQaIoieBR4lhYJ?= =?us-ascii?Q?8F1LOHgwC/ajB/asiOwbIwiBBAGHoA+zi/vFs6UpZCKBwb4q3+JS5hZZS62C?= =?us-ascii?Q?YKRysEveW6OGe+nZqyCwJFBdocdQKvIAV8rj62RgHLOE9H7BHyXf3YvtyJLY?= =?us-ascii?Q?UsmWnTEE6XhhuxNmMIr1Pv9YZpJA2lQIG7Fdi+I4vtNbatMNg7IAc1sj5qXM?= =?us-ascii?Q?dne9GtfkrZnd6jaAV9TA8nrI197ajU805a8MhdABKlmljbir12INWD9rQMn8?= =?us-ascii?Q?4fjoubbn6WHuF6gXB4EMcYGRUyIiG0KyjqHYZL/z+UhbEDI6Y5R7G6RRRr3P?= =?us-ascii?Q?VAiOhMZn+r1xxzm8aaTL0C/tqasCb7GH8OuiHm7u0a6Z4QAA5UOUxHLSlkBw?= =?us-ascii?Q?TChfKip2cXsDpuHRMTD8AHq7DGl4+qeryv3caXxaa4XBdtNvQArmR6mLYhSv?= =?us-ascii?Q?TM+GJ1NGSKVhKCqMBOEFy8Gpp5fP44ULA9NLKV7mLrB3Bx3sVhzdBJMRYjW0?= =?us-ascii?Q?AVqj8LrWTEK20GOejk4noe4/N8ubhZ9KDLTV/HJBCqRr2U2Evl7GUEdWLJ3U?= =?us-ascii?Q?EaUC5yRuqtSykta2IJwmxQJ8E/b7LXP7ME1eohup5vXoWwbtYC4v2gZzCS//?= =?us-ascii?Q?Ybh0H/Jd23GRjKhWfW5/bmMFaIfNaB1Vta4arTZvMDwc6RK+aLkWwxgsq9eV?= =?us-ascii?Q?gLitfj5LpgLlSzKd9zJnztw9eAolKYRwntSkYMO5nKP3Qtd3mHA9Ps6PHijC?= =?us-ascii?Q?rq/DwqJ+phmHr022PiHr4/q9Pfgu/3U78d9g1Vqc30uqvMhX+rYUEofiuZLR?= =?us-ascii?Q?N9e4hM6h57PCN4u31JtjbaZUXOEmvz2lhlLn7MF1ETm6k8Pq67+1jyRoio0V?= =?us-ascii?Q?atR5FBOJJlwSlpqY1eLL5lR3+jyT0hsQIqX9DJvvRWggU4Hpqtey8z/3iu3H?= =?us-ascii?Q?u/jnkwBHSkKxdwu6bmUqwj3O9/E3UWh9Z1yB+j8/SrTKFizrm/ya6JZUtFsl?= =?us-ascii?Q?74ZVtbGwsK64NZaIi7r+WDCktC9HAsZzweAD8DvTHi+UDoh/bJPoC3H1cnQz?= =?us-ascii?Q?KNkwsZWg5HAgPXy1r4eVYumvne7qSCFz77iYjiH/f+Qmk5ZGt7WU/Y7GH0KU?= =?us-ascii?Q?gaGwiWvDgQYE67AIK5W7EIUO1iqoM1234EsJzkU1znBo68XYwfix+t+sRRjM?= =?us-ascii?Q?fAGuIPv4C9ZWMKshn/KiA3PX2syXHkmpQu9nsndHvbOIaxbn+9jTU6exrGe4?= =?us-ascii?Q?ytCBlCvz4CrJSS28asslhMXLrHERneMIXYcWrYVX1qk+iPVm9KWXcmhhDe8r?= =?us-ascii?Q?BySPf4WogmEJmWNfFZfmTApGKEn4wmu5Hd9LWI0JrSlL2xf7x4Bdq344oKQ0?= =?us-ascii?Q?WJigqwsvz3V0PkBx2jGCKwBXQp8Q6X8RhRtP1hg0mJti3R9oib4lh8SJPRm7?= =?us-ascii?Q?iW+lGRME0+vSXsL9ZVJX0Y+O15xY6B21ThBy+UUKampkf5ZiHS75HLQQ6seY?= =?us-ascii?Q?NVYq25CskiocgLhOBCxRvFgGt/zj+S8Lhss3l8x3TN75j6TiiUSsX6a9zx3g?= =?us-ascii?Q?RPoOy7CpqA=3D=3D?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: eb633827-9363-4668-3549-08deef0c500b X-MS-Exchange-CrossTenant-AuthSource: DM6PR12MB4827.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jul 2026 14:02:09.6244 (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: L+wXPONgHlBD4qHEInF1TtR+DbATHchl1K4Wk6w/ylQHIjw7BHVimcWIh1Y1e9v9q8a0ks0j6XN8ie0ra8DIRQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB7661 Hi Mete, On Fri, Jul 31, 2026 at 02:53:55PM +0200, Mete Durlu wrote: > On 29/07/2026 18:32, Andrea Righi wrote: > > find_new_ilb() selects the first idle housekeeping CPU without > > considering whether another thread is running on the same physical core. > > On an SMT system, the idle load balancer can therefore activate both > > siblings even when another housekeeping CPU has an entirely idle core. > > > > On most SMT systems, this is not problematic because the idle load > > balancer is a short-lived activity and the transient wakeup of a sibling > > has negligible performance impact. > > > > However, this can be particularly costly on NVIDIA Olympus cores used in > > Vera. Briefly activating an otherwise idle sibling can reduce the > > performance available to the other sibling and this effect does not > > necessarily end once the activated sibling becomes idle: after the ILB > > finishes and its CPU enters WFI, full single-thread performance is > > restored only after the sibling has remained idle for a qualification > > interval (10 Ki cycles on the tested Vera system). Repeated short > > sibling wakeups can therefore sustain the interference even with little > > actual overlap. > > > > Prevent this by preferring an idle housekeeping CPU whose entire SMT > > core is idle. Retain the first idle CPU as a fallback when no fully idle > > core is available, so NOHZ balancing continues to make forward progress. > > Once a partially busy core has been examined, skip its remaining SMT > > siblings to avoid repeating the core-idle check on wide SMT systems. > > > > Tests performed using an ad hoc GEMM benchmark running one CPU-intensive > > task per SMT core within its CPU affinity mask improved from > > approximately 6.2 TFLOP/s to 9.4 TFLOP/s. > > > > Note that this preference may wake a fully idle physical core instead of > > using an idle sibling of an active core, potentially increasing ILB > > wakeup latency or energy consumption on some architectures. It may also > > scan additional CPUs before selecting the one to run the ILB. The > > selection falls back to the first idle CPU when no fully idle SMT core > > is available. Non-SMT systems continue to select the first idle > > housekeeping CPU. > > > > Cc: K Prateek Nayak > > Cc: Shrikanth Hegde > > Signed-off-by: Andrea Righi > > --- > > Changes in v2: > > - Avoid repeated is_core_idle() checks on wide SMT systems by pruning > > the remaining siblings of a partially busy core (Prateek Nayak) > > - Link to v1: https://lore.kernel.org/r/20260728214442.1648483-1-arighi@nvidia.com/ > > > > kernel/sched/fair.c | 48 ++++++++++++++++++++++++++++++++++++--------- > > 1 file changed, 39 insertions(+), 9 deletions(-) > > Hi, > > thank you for the interesting patch! I am testing this on s390 > to see how it impacts our platform. After reading the discussion > on v1 and reviewing the code I got minor nit. See below; Awesome! Let me know how it works on the s390. A comment below about your nit. > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > index 37001c63452e5..b9e26938fb12a 100644 > > --- a/kernel/sched/fair.c > > +++ b/kernel/sched/fair.c > > @@ -13965,28 +13965,58 @@ static inline int on_null_domain(struct rq *rq) > > static inline int find_new_ilb(void) > > { > > int this_cpu = smp_processor_id(); > > - const struct cpumask *hk_mask; > > - int ilb_cpu; > > + struct cpumask *ilb_cpus; > > + int ilb_cpu, fallback = -1; > > + > > + lockdep_assert_irqs_disabled(); > > - hk_mask = housekeeping_cpumask(HK_TYPE_KERNEL_NOISE); > > + /* > > + * Reuse the per-CPU select_rq_mask, which is protected from concurrent > > + * use on this CPU by having interrupts disabled. > > + */ > > + ilb_cpus = this_cpu_cpumask_var_ptr(select_rq_mask); > > + cpumask_and(ilb_cpus, nohz.idle_cpus_mask, > > + housekeeping_cpumask(HK_TYPE_KERNEL_NOISE)); > > - for_each_cpu_and(ilb_cpu, nohz.idle_cpus_mask, hk_mask) { > > + for_each_cpu(ilb_cpu, ilb_cpus) { > > if (ilb_cpu == this_cpu) > > continue; > > - if (idle_cpu(ilb_cpu)) > > - return ilb_cpu; > > + if (!idle_cpu(ilb_cpu)) > > + continue; > > + > > + /* > > + * Running the idle load balancer on an idle sibling of a busy > > + * SMT core can reduce the capacity available to its sibling. Prefer > > + * a CPU whose entire core is idle, but retain the first idle CPU as > > + * a fallback so idle balancing can still make progress when no fully > > + * idle core exists. > > + */ > > + if (sched_smt_active() && !is_core_idle(ilb_cpu)) { > > + if (fallback < 0) > > + fallback = ilb_cpu; > > + > > + /* > > + * The core is not idle, so there is no need to check > > + * any of its other SMT siblings. > > + */ > > + cpumask_andnot(ilb_cpus, ilb_cpus, > > + cpu_smt_mask(ilb_cpu)); > > Just a nit but; > > I think the purpose here is to move between cores if smt is active but > current logic seems to be doing that only after an idle cpu is found. > Consider that we first found an idle cpu but the siblings are busy, > after we move to the next core we start traversing per cpu again. > > Wouldn't it be better if we always move per core after a fallback is > found? How about sth like below? The idea mekes sense, however... > > ... > for_each_cpu(ilb_cpu, ilb_cpus) { > if (ilb_cpu == this_cpu) > continue; > > if (sched_smt_active()) { > if (fallback < 0) { > if (!idle_cpu(ilb_cpu)) > continue; > fallback = ilb_cpu; > } > /* > * Running the idle load balancer on an idle sibling > of > * a busy SMT core can reduce the capacity available > to > * its sibling. Prefer a CPU whose entire core is > idle, > * but retain the first idle CPU as a fallback so > idle > * balancing can still make progress when no fully > * idle core exists. > */ > if (is_core_idle(ilb_cpu)) > return ilb_cpu; ...is_core_idle() doesn't check the supplied CPU itself, only its siblings. So we could return a busy ilb_cpu if all of its siblings are idle. I think a safe improvement, following your logic, could be this: for_each_cpu(ilb_cpu, ilb_cpus) { if (ilb_cpu == this_cpu) continue; if (!idle_cpu(ilb_cpu)) { /* * Once an idle fallback exists, a busy CPU proves that * this core cannot be fully idle. Skip its siblings. */ if (sched_smt_active() && fallback >= 0) cpumask_andnot(ilb_cpus, ilb_cpus, cpu_smt_mask(ilb_cpu)); continue; } /* * Running the idle load balancer on an idle sibling of a busy * SMT core can reduce the capacity available to its sibling. Prefer * a CPU whose entire core is idle, but retain the first idle CPU as * a fallback so idle balancing can still make progress when no fully * idle core exists. */ if (sched_smt_active() && !is_core_idle(ilb_cpu)) { if (fallback < 0) fallback = ilb_cpu; cpumask_andnot(ilb_cpus, ilb_cpus, cpu_smt_mask(ilb_cpu)); continue; } return ilb_cpu; } This should implement the right behavior: - before finding a fallback, inspect CPUs individually because another sibling might be idle, - once a fallback exists, a busy CPU proves its core is not fully idle, so we can skip the entire core, - for an idle CPU, checking is_core_idle() remains valid, because its own idle state has already been established. What do you think? I'll run some tests on my side with this new logic applied. Thanks! -Andrea > cpumask_andnot(ilb_cpus, ilb_cpus, > cpu_smt_mask(ilb_cpu)); > continue; > } > > if (idle_cpu(ilb_cpu)) > return ilb_cpu; > } > > return fallback; > >