From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from PH8PR06CU001.outbound.protection.outlook.com (mail-westus3azon11012012.outbound.protection.outlook.com [40.107.209.12]) (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 C88895CDF1 for ; Mon, 16 Mar 2026 03:41:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.107.209.12 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773632476; cv=fail; b=dUo5MSZp2oN1IsZm++2zK80UYeMh1LBdDzVebtTATppkltwF/pUoGqlLA4NmLSEn9CXoXEBAFN0CxQP/r861mG3DrAPbPu5uU+VWLyraEXpNrQluErlz/sxzmeH1U8LJP51VxIGMQS4DU9Apc1yT2g2fESeFMUhog9A6nxroakE= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773632476; c=relaxed/simple; bh=pnqXs0q26MPhYAx/gNjJglD3Q3kGFaJIU7yMuDStt8E=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=OJ8PtuODrRrbCgrXIDe58Ij9PtopcC1Z6yMBZ+gBtbR64+WQT3Zxqx+AtaKDonuvzRTkpPQW1TccfQ6fjC62ZjNU4rXRq1S3iyP8AJQ5PRTCAp1e16ui/aBBBkm+0SH2zyYwunRUsz4sp1jO+MtTJ2M0o4oAdamlQhqTFxE2OVs= 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=MACAKmJ3; arc=fail smtp.client-ip=40.107.209.12 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="MACAKmJ3" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Qy21kI0S03szJi7X9SYUafR+17KgwzOO+Ruo0XzU+pwiNopARpfSmMf1Zuo+dJTF8R/+4hnLvbC2TZNBD2SrNZmHmBbdj1mBGoyOrkBK0ukN8PkQHl3TA/0XnTQlpYS8lnLXd6UzgbmYDcPdumnjwAKkfR4K3sFDwd239/XFBB5NabbwLHIQ4vD4+w/QvaglniPFOQJTOC9Zk0z0XdPHwEFUPRurMsvcK4sHfjAQ+YrvuCB1njCc4oGd6wFjiFbpfKN9HRQh5AX6b+fWV30UM4wgR0gBvgDhs9J1Qe4pz0cKpFwN/r/CH1Jt7dY/T+CBtB9yMXpWKyZXLQSG9JHEjQ== 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=JPZwwLxmAU8iGPiQAArLVbOorO8E5cKVEY1o2YEnqS8=; b=Lr4N5+Y2fJpnwZ7g/89Kb/z+PfWwIcffK/AUkRX2iHfP+muRai7sleT+82Xsty1rXLf04N3MpqRf3vWdRXykYEw1X30qlJyAZ+b9JO3jwAFlWJ4QIHDM38rjJMJ59VZSveXEcwnW9InE+dMnozC5wvaawrmXpqYDHySLeaguBzzuHwyJ+1NPje2QhHOmJNX8qjq+hRlD509zeZZI39g32H/8XedBtQRux0GxNhbdY7e6Z1tqn0HvqoQQ+Mn7BqzAZhGleeY36v5n5GiqUtpnch4Cla8LnLN9UtmYM/NLjnAObn0q40abgnFlcM1UOACjZBLWTCzlo6Hlf1wnxhYbww== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=arm.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=JPZwwLxmAU8iGPiQAArLVbOorO8E5cKVEY1o2YEnqS8=; b=MACAKmJ3Dt52pOdz7P6wkr2c9KfGazCNEMdHB+agWxCO0RBBmwAEk7jgztBxso08AijSONIvXIuc98xumNizBhfFa3OnsdTKJsfK6qLF6O9akrMbnyA2BJIGF073OR/p2PPAzbnLZCtezJ/lvOSlJJ0ADDGK9VJBVcYbQL4WnLo= Received: from SN7PR04CA0041.namprd04.prod.outlook.com (2603:10b6:806:120::16) by DM4PR12MB8497.namprd12.prod.outlook.com (2603:10b6:8:180::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9723.16; Mon, 16 Mar 2026 03:41:10 +0000 Received: from SN1PEPF0002636B.namprd02.prod.outlook.com (2603:10b6:806:120:cafe::84) by SN7PR04CA0041.outlook.office365.com (2603:10b6:806:120::16) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9700.24 via Frontend Transport; Mon, 16 Mar 2026 03:41:00 +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=satlexmb08.amd.com; pr=C Received: from satlexmb08.amd.com (165.204.84.17) by SN1PEPF0002636B.mail.protection.outlook.com (10.167.241.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9700.17 via Frontend Transport; Mon, 16 Mar 2026 03:41:09 +0000 Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Sun, 15 Mar 2026 22:41:09 -0500 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Sun, 15 Mar 2026 20:41:09 -0700 Received: from [10.85.36.114] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Sun, 15 Mar 2026 22:41:05 -0500 Message-ID: Date: Mon, 16 Mar 2026 09:11:04 +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 v4 2/9] sched/topology: Extract "imb_numa_nr" calculation into a separate helper To: Dietmar Eggemann , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Valentin Schneider , CC: Steven Rostedt , Ben Segall , Mel Gorman , Chen Yu , "Shrikanth Hegde" , Li Chen , "Gautham R. Shenoy" References: <20260312044434.1974-1-kprateek.nayak@amd.com> <20260312044434.1974-3-kprateek.nayak@amd.com> <7182d0d5-be42-42bb-8864-189ddedbf534@arm.com> Content-Language: en-US From: K Prateek Nayak In-Reply-To: <7182d0d5-be42-42bb-8864-189ddedbf534@arm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SN1PEPF0002636B:EE_|DM4PR12MB8497:EE_ X-MS-Office365-Filtering-Correlation-Id: 2229e51b-3f12-4c95-083a-08de830ddd03 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|376014|7416014|36860700016|56012099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: IBFM8YizGNAEOd8BYdHn2uqPKV8/aUlLf0eiZ8+ntPMB8ZZwFJafOsicI44DwbE+jT52ebE7+0eCJ6a+KlO7F619+c5BpFzPT8zxxn+898g3C+yKdp6FWHjAB+n/he4r/I/8jRKtwv1yaAKh9dYTis1Relc56kYx8g4hCEWFuoHhLs3Mt3z+gmqyvmhaOsULx70u2I8AJng8YHsZAS7CFMSeUzhfsyfpbO8oInl2whZvv2V0/dMPDhmyqqrZYlIyf8YXFM0BkMRjtBhkJYPexukxwkYY2ZpPeua2vuaLozygBUv9XiT7ri9WvIFB/SCGHxq8c/5D5FqAm9u4ElP7640Wdq3VMP2AGISgiYljh4Fgb2HaVpUWSp9gp/6ZR9hZd7bpy2AKj64kjedwwfv/Vfts96p/Or5XB2rZqCQfzld+3gRUTv0DIdrK3f24R9eZMmwvTID64I6dQtBCCBn6Rxav0aYQQrzfEfogFd1lQ2YgLFFPMUGdFkNA32Ci9Eo8Mx24cmxw3Df2WPmG8qNNQfIkOdCMy1aJAdFXQlnMBr4z84sL7RKckD0ZUCoPRYsTuSHEDZ9DOZBdXRpcJZ0sul1hM9x9IppZTUD+LxSnWIaJsOPy2plbMPlo+XGgCUNSdT07sWz9ROjuKqVVVlYTFCoH6VVPVFfp+avzzMPZpu0zp5yGWq1mbRr1aPiE9aUOP7m45JJzgKv1Ye1vB0v2wfUAVU0OdcUyZEUt3gP7Y4t5ztyEa9zZ3h1e41B2TVGVY34CruUZtT1YdaojmYMg9w== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(376014)(7416014)(36860700016)(56012099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: PmDebRzrZfc+8xGrAkT/DR8mOtxiUBesozYV7qTZFUZ7abXAnCDySSB87CMN7979efdbVRYvWt6yxcHPubzyv6KnCah/pgOIqsOzbeuGjQWz4/RQir1YX/ny1cCDy8ijLEuAZpqNIqXvtith10jUGcOABkdtwODQcvutrt1njLHYu8GmhzSQcpjtCnbVMcxDTnBcyjjM6AxOUjcAcIS8R3R7MgmrwAijaPQTwJO7hZUMNRJL9NFmkbimOMNFP+aiZw0wRZ2zzyDno7YkCjzG8z9yXudx6pfahTxtY+KH+w4EZscSqQ99HZP4GNsGQyQTy37v22ZOGh2OKd+9v9tKsmqq5UyT/Vdf0RB41GZWqkX/qtfpLeSFP/bguvDlAJAjngdCtk+r9a80sd3XpjuvxuhYMRIzqM3UUw0d0vbVab/+5AHj6U9IkSmpDwxHzfpG X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Mar 2026 03:41:09.8303 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2229e51b-3f12-4c95-083a-08de830ddd03 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=[satlexmb08.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SN1PEPF0002636B.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB8497 Hello Dietmar, On 3/16/2026 5:48 AM, Dietmar Eggemann wrote: >> + /* >> + * For a single LLC per node, allow an >> + * imbalance up to 12.5% of the node. This is >> + * arbitrary cutoff based two factors -- SMT and >> + * memory channels. For SMT-2, the intent is to >> + * avoid premature sharing of HT resources but >> + * SMT-4 or SMT-8 *may* benefit from a different >> + * cutoff. For memory channels, this is a very >> + * rough estimate of how many channels may be >> + * active and is based on recent CPUs with >> + * many cores. >> + * >> + * For multiple LLCs, allow an imbalance >> + * until multiple tasks would share an LLC >> + * on one node while LLCs on another node >> + * remain idle. This assumes that there are >> + * enough logical CPUs per LLC to avoid SMT >> + * factors and that there is a correlation >> + * between LLCs and memory channels. >> + */ >> + nr_llcs = sd_llc->parent->span_weight / sd_llc->span_weight; >> + if (nr_llcs == 1) >> + imb = sd_llc->parent->span_weight >> 3; >> + else >> + imb = nr_llcs; >> + >> + imb = max(1U, imb); >> + sd_llc->parent->imb_numa_nr = imb; > > Here you set imb_numa_nr e.g. for PKG ... Ack! That is indeed a redundant assign since it gets reassigned in the bottom loop. For this commit, we have kept it 1:1 with the loop that existed before in build_sched_domains(). > >> + >> + /* >> + * Set span based on the first NUMA domain. >> + * >> + * NUMA systems always add a NODE domain before >> + * iterating the NUMA domains. Since this is before >> + * degeneration, start from sd_llc's parent's >> + * parent which is the lowest an SD_NUMA domain can >> + * be relative to sd_llc. >> + */ >> + parent = sd_llc->parent->parent; >> + while (parent && !(parent->flags & SD_NUMA)) >> + parent = parent->parent; >> + >> + imb_span = parent ? parent->span_weight : sd_llc->parent->span_weight; >> + >> + /* Update the upper remainder of the topology */ >> + parent = sd_llc->parent; >> + while (parent) { >> + int factor = max(1U, (parent->span_weight / imb_span)); >> + >> + parent->imb_numa_nr = imb * factor; > > ... and here again. > > Shouldn't we only set it for 'if (parent->flags & SD_NUMA)'? > > Not sure if there are case in which PKG would persist in > > ... -> MC -> PKG -> NODE -> NUMA -> ... ? > > Although access to sd->imb_numa_nr seems to be guarded by sd->flags & > SD_NUMA. Indeed! "imb_numa_nr" only makes sense when looking at NUMA domains and having it assigned to 1 for lower domains is harmless (but wasteful indeed). I'm 99% sure we can simply do: (Only build tested) diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c index 43150591914b..e9068a809dbc 100644 --- a/kernel/sched/topology.c +++ b/kernel/sched/topology.c @@ -2623,9 +2623,6 @@ static void adjust_numa_imbalance(struct sched_domain *sd_llc) else imb = nr_llcs; - imb = max(1U, imb); - sd_llc->parent->imb_numa_nr = imb; - /* * Set span based on the first NUMA domain. * @@ -2639,10 +2636,14 @@ static void adjust_numa_imbalance(struct sched_domain *sd_llc) while (parent && !(parent->flags & SD_NUMA)) parent = parent->parent; - imb_span = parent ? parent->span_weight : sd_llc->parent->span_weight; + /* No NUMA domain to adjust imbalance for! */ + if (!parent) + return; + + imb = max(1U, imb); + imb_span = parent->span_weight; /* Update the upper remainder of the topology */ - parent = sd_llc->parent; while (parent) { int factor = max(1U, (parent->span_weight / imb_span)); --- If we have NUMA domains, we definitely have NODE and NODE sets neither SD_SHARE_LLC, nor SD_NUMA so likely sd->parent is PKG / NODE domain and NUMA has to start at sd->parent->parent and it has to break at the first SD_NUMA domains. If it doesn't exist, we don't have any NUMA domains and nothing to worry about, and if we do, the final loop will adjust the NUMA imbalance. Thoughts? Again, this commit was kept 1:1 with the previous loop but we can always improve :-) > >> + parent = parent->parent; >> + } >> +} >> + > [...] -- Thanks and Regards, Prateek