From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazon11012034.outbound.protection.outlook.com [40.107.200.34]) (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 B52DA43BDB6 for ; Wed, 29 Jul 2026 10:39:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.107.200.34 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785321559; cv=fail; b=XRuHvj78msqtteh8yvMeyBYjlm8mTIWpTSSr+OsPs9U99scVujPjrqjE8HyatGodBr/uHOL7s4aAb1QtCUs96wUSuzCYhz3rF9naN0yeFPP1uQrpRucLuX3aMLVnuaPWdvtW7NKMUcHAnoVAxvglNlkaenQa1Zy1SdIHt5z7iP4= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785321559; c=relaxed/simple; bh=b/cAn5rTsdonCgwEuChpev7sBBwihOnSTBO7lc5p+/A=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=Nq7m33JNztZzI8D885bDzrimk+uyjCGxOLF/3tDL+QW4qwoM2s0XONRhXktoyGYa7lW+O2iOgXxer0gTskRr5JPd/SLyBzsA/XWleh6pZ7CPb+4BEmfNm1J77mpWYFODK1tmmS5boTM3iRPUTia/JPCNd7Z7J0wxER+WuSnZqPI= 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=s5wq5l1n; arc=fail smtp.client-ip=40.107.200.34 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="s5wq5l1n" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=MQoWwjGLng8Ns3eLtPpCv+hUKumsdeQVilC35iGBHp/zo77ujWnxJksEXWxAln5OsEuith6/d8bD172lLLoDxnDIfC8900YPIU6qEU9ivSSBiND0aZqAgWsUx6PjJc0rAE3fLic8UZhr9XgVhnjgx1Qd72jMdLaY2OO7llwHifIzjkseHcOsBXdmXDzWSscz4US1OwjIHs9r3sCX9chmhCc2J0XhfJLVuL3zhL4k1ObYLclM0QImMvBMUQBVNS9YwG9Ywvak1rVz36RCYXSZQTI+YZb9kRL1++GmWZh+iDmMTm94vkXuhPVeu57vS627/QYu+aBtVdwKBeWs7zfSlA== 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=2E2RHvFttcNAcMMjogQhfstuH0bZqG10GxSjbgW05Os=; b=JyuwinUIdMu9YDCVqFLTA7Omzxmz9BYMcJ+VthlFH+L/B2dVPcrUs+GFCyjAMWCVk6v5RHbYbgbPq78LxhPiNnE2Bf2YjeF+vZNK+ZFIskqgvJFOTo8PnWqWzg5Q9StXxQ9nGBPi7ohqIYbXWzYudeKIo7rjr6GDZbf3hECKW371/peL58XrqRucPa1VYxvj7F1moZjEhAFl8PqTD4K7iZHg7Lzu+MuiY2BUyMZULGXDiH8YQcZ3nQCBII2MAtqL0kjv/CmAnof/qIXuDOdTrNCvHUyeSpp9hid2g5RZmXsGMMkQ5Lih50Z0PfSXflMRM+MealkSuVzzNl1+MZHr0A== 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=2E2RHvFttcNAcMMjogQhfstuH0bZqG10GxSjbgW05Os=; b=s5wq5l1nUrWoXz29eEsWHpaQtEszlvz8nvb4YePSxGdWfvp0VKnXTJOO0bEIp1USo+yYihgpvljU5spYFahl0zePGyp2lycr3Gt1HA3F2W3c7/Z5j7VfsbKEuER8o9d0q3WpxFkHxgYKpJclxsRVFfJM4iaCcN9evrSyP9rn5MI= Received: from BN9PR03CA0316.namprd03.prod.outlook.com (2603:10b6:408:112::21) by CY8PR12MB7633.namprd12.prod.outlook.com (2603:10b6:930:9c::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.270.13; Wed, 29 Jul 2026 10:39:11 +0000 Received: from BN1PEPF00004689.namprd05.prod.outlook.com (2603:10b6:408:112:cafe::90) by BN9PR03CA0316.outlook.office365.com (2603:10b6:408:112::21) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.270.12 via Frontend Transport; Wed, 29 Jul 2026 10:39:11 +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 BN1PEPF00004689.mail.protection.outlook.com (10.167.243.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.270.5 via Frontend Transport; Wed, 29 Jul 2026 10:39:11 +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.41; Wed, 29 Jul 2026 05:39:11 -0500 Received: from satlexmb08.amd.com (10.181.42.217) 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.41; Wed, 29 Jul 2026 05:39:11 -0500 Received: from [172.31.184.125] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.41 via Frontend Transport; Wed, 29 Jul 2026 05:39:06 -0500 Message-ID: Date: Wed, 29 Jul 2026 16:09:05 +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] sched/fair: Prefer fully idle cores for NOHZ balancing To: Andrea Righi CC: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , "Mel Gorman" , Valentin Schneider , "Christian Loehle" , Shrikanth Hegde , Phil Auld , References: <20260728214442.1648483-1-arighi@nvidia.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: BN1PEPF00004689:EE_|CY8PR12MB7633:EE_ X-MS-Office365-Filtering-Correlation-Id: d4a51336-d157-49bc-ac94-08deed5da08d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|23010399003|36860700016|82310400026|1800799024|13003099007|10067099003|4143699003|11063799006|56012099006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: 5RHIXdXYTQxuPtTnLKwVKYJAyu7d1J7OZLU+wdE4nIpF+fy77pV5dV6jvJdbLEGZoVdw6vBTZ4SvyHA8cBije9MMA/SrbUn97TVV8gAfXShrqE2Vm4aPJzBL9byPNvWXQO3QfG1k2rvsNsN9XbYbJ6QEyTmUmUVYkrsEDYLMlyHfq87kFVb0/S4pJW2y628M5txJ1rOjUBlgzhcmIIsXNU3Vu5WvOOjcOZ97MsdmqHuErWIpTY3t2qUhamqO8VAjatcc1x5GxCnTKcfkDz05ttptngsuJnogiufP7CAY6DsH45oK5NYnZ5DnOWV3dnU77NYYMLZ7kgHDFLtk1eG70aIv9rVb3qBrt1+F67nsUf7PioJu2xBQDx1E9Lo/1Kg4voRoOuWpIyDKTqngZPXdcNAJZYZyb4VqfdO0CY1XE2jaHcng8TJ+7tYZkpW7c/5LerjvuL2ZokMT6KdufXVbHVfBz9+0wzzol6vvld2OxEeSd3+obKLk2EwMm+YTs5RwXEi9QV9Snh8HMKFA88OJUBMCp/YLpzU87p+oVzZ/Rvx1ob1IYdDtjuDdccG4FmPHQi13Hixi5zwpP99Rh7wgVD1ByW/iLTQmGIfuIRPRGd6WkNSOtTZYnQKoPoecDx5V1dcmkkaM5OSdaonyjAhDr0RoMVM2D5LRRKO+RG+3rfwGXMRuOmuUKjTQhjtcnttKunANGX34hrJgLatFAcBbow== 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)(376014)(7416014)(23010399003)(36860700016)(82310400026)(1800799024)(13003099007)(10067099003)(4143699003)(11063799006)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 5E3GORQP6y1GN/NfMXfhAz2IGLx64iUjI2fAexB6Y4g6Iz0q8bKAgnugDwMYz0lpxciXjgkUyKFqPmvOFURzNC4pJZMu80Sd+rDmt3S792cY8lxJhD2gcr33Lp7Ki3lTygYA1oZI1H6Nj67KsLg0Szl9F3X1/3qGO1TNvCtZGc4razYmbtpfVk5i5a/5q+He7lRRV2MK1F5haHmbhw4rmGsV8fi4WwAcqVMWHm/TJBXhL1r0Lg1GGe2roZxBqVJldce7Qprgy5GeKA2v5TmniMC+GoV+4IobO1QXwTsWRt1q8bLbAHV0+V0/M73cb39zPmXtNeyoTPNEemER+SPEPTYxVQDD5ozhyqHRAeaK5gWcIyoSho1Jucppe3NzVmmuGqqGCgGW5JyS2ggpBXh2zvdr6A1JlFjTVe6hZM5aOmkB9duwER6ndWbZKw238lsB X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jul 2026 10:39:11.4165 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d4a51336-d157-49bc-ac94-08deed5da08d 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: BN1PEPF00004689.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7633 Hello Andrea, On 7/29/2026 3:05 PM, Andrea Righi wrote: > Hi Prateek, > > On Wed, Jul 29, 2026 at 01:48:14PM +0530, K Prateek Nayak wrote: >> Hello Andrea, >> >> On 7/29/2026 3:14 AM, Andrea Righi wrote: >>> @@ -13974,19 +13974,32 @@ static inline int find_new_ilb(void) >>> if (ilb_cpu == this_cpu) >>> continue; >>> >>> - if (idle_cpu(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)) >> >> nit. >> >> is_core_idle() here would iterate all siblings and on systems with SMT-4 >> and SMT-8, that overhead is apparently visible when one thread per core >> is occupied based on past optimizations like f8858d96061f ("sched/fair: >> Optimize should_we_balance() for large SMT systems"). >> >> Copying the same approach from that optimization, can we do: > > Good point. Without removing the remaining siblings, we may call is_core_idle() > repeatedly for the same partially busy SMT core. I'll repeat my tests on my Vera > system and incorporate your suggestion in v2 if I don't see any regression. Thank you! From my experience, it is not very visible on SMT-2 but Shrikanth can vouch for the overheads on SMT-4, SMT-8 systems. > >> >> (Only build tested) >> >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >> index d78467ec6ee1..814bce21ccf1 100644 >> --- a/kernel/sched/fair.c >> +++ b/kernel/sched/fair.c >> @@ -13849,21 +13849,35 @@ static inline int on_null_domain(struct rq *rq) >> */ >> static inline int find_new_ilb(void) >> { >> + struct cpumask *ilb_cpus = this_cpu_cpumask_var_ptr(select_rq_mask); >> int this_cpu = smp_processor_id(); >> - const struct cpumask *hk_mask; >> - int ilb_cpu; >> + int ilb_cpu, fallback = -1; >> >> - hk_mask = housekeeping_cpumask(HK_TYPE_KERNEL_NOISE); >> + 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; >> + >> + if (sched_smt_active() && !is_core_idle(ilb_cpu)) { >> + if (fallback == -1) >> + fallback = ilb_cpu; >> + /* >> + * If the core is not idle, and first SMT sibling which is >> + * idle has been found, then its not needed to check other >> + * SMT siblings for idleness: >> + */ >> + cpumask_andnot(ilb_cpus, ilb_cpus, cpu_smt_mask(ilb_cpu)); >> + continue; >> + } >> + >> + return ilb_cpu; >> } >> >> - return -1; >> + return fallback; >> } >> >> /* >> --- >> >> It is safe to use "select_rq_mask" here since this is the tick handler >> trying to find an ilb_cpu and "select_rq_mask" is only used in contexts >> with IRQs disabled. It can probably be renamed to suggest that it is >> safe to be used in any IRQ disabled context as a temporary mask. >> >> Thoughts? > > Agreed. We can also add lockdep_assert_irqs_disabled() to find_new_ilb() to > better document and verify the condition that makes reusing select_rq_mask safe. That works too but it just looks a bot odd to have the selectrq_mask in a load balancing function. > > Speaking of that, instead of renaming it, would it be better to provide a helper > to access select_rq_mask with lockdep_assert_irqs_disabled()? I'll defer to Peter on that :-) He had previously suggested renaming it when there were discussions to reuse it here https://lore.kernel.org/lkml/20260320114312.GB3558198@noisy.programming.kicks-ass.net/ -- Thanks and Regards, Prateek