From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from CY3PR05CU001.outbound.protection.outlook.com (mail-westcentralusazon11013034.outbound.protection.outlook.com [40.93.201.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 840BC39768D for ; Thu, 12 Mar 2026 04:44:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.93.201.34 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773290699; cv=fail; b=TqqscaTbliF+nkBq8ZyWa8tBeFi7qyg0L4zF6j9jAILF3+ShIv8IOpRIbjNXcqzicRxvnxRDkxj10feQoKmSOa1jIPYJCvUtKtFC+116ETvUvhsZ+0lIJ5Dyy6mypo69ez6lAzJSSimcc24i31ap8ArV1HKvXyGfZfDVSReDHDQ= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773290699; c=relaxed/simple; bh=zzbiN3+0kRigAI8CAn3Oj65l3qXpaYgrPYtOR6ipdnw=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=Sh6RJf7iMGGPe9LwEe/Uv7nMZ9MEFDIYVDmSWLpn7RpTEyMO1slvC845iQQzKk3co/tsKvhouaZkBHkrYpF6hfoofp093I4kX+IATY4ouOTKOqvP+IlxqZ8f0ZmmgKDFDFp0zufUohZpU+D51Kb8hqJcL+awYfhcGIWch/CTnuI= 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=OyeoOj+m; arc=fail smtp.client-ip=40.93.201.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="OyeoOj+m" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=IJAEXnpGOTslv7meHiXveqbsLi9Jo4LqFuKnwnmck34c5IRBTjyFUJ47oU7BJU125btGRVZTHn5X7sk1eDv1PSg8llYfoq+RmVGiwRzcy2y+48SiHAfZlRNDnvd5fBso3PiadshcB8cdxhnhbx00ThsKQJnvWHPLCFtUwLL43Ty98nSC2xxsi0okR7on+2wDQNKWo7K4QgTym2FEnQp19rATBD3Pa/63fYH5ewumvsJgk8VlXvaID8FUXZwyrB6nTqv+lqIqgLza5+XyfpLm3O6/6QH51ojX10HtkQnYc3meEeXOshnIvhA6RlQNdHrUVg4I8+VRTvuUpLXWSrouGQ== 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=JCoCCuo/Pv78LIj+OnIwpr6s8+1eF+GdJlCzkSYFNH8=; b=NQo1xLvdwrSi/mcurdzFon4w588qBOg/H2rRcWDEG/m7TtJOkihrsy6HZ88RSe7SMMYpeI69n+EYV3scAuUUILWpC49SQUjAHOsFeNd5r9o1OKd9ZGg80nA4l8zswiLYrxV2hlGPU3ekkse7F5d/sKB9lFzb7hj8mLiZ+dVM4MuAzCefvxNqHvzeQoxDBbkM5jH8LFrMLwQ6JKs6Uj/RSDhRd/ZUcqjChuCwQPh0O+w846DTuY8ZmhYzohUTO0OoFNQ8dW9qhks0znCGbhux6Wtnkg9ma9zli9HLBCKuzZg3I5LMrzgh2pBAMeEELZeG0xTR58m5ABEK5z5B9WGfow== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=redhat.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=JCoCCuo/Pv78LIj+OnIwpr6s8+1eF+GdJlCzkSYFNH8=; b=OyeoOj+mIcJ+LBsIlktxv6TRN3CmkKzmvHJZou60ay7kHJumcRZyNExoN2zm4x7Ki+LpesRG5C7WR5TXCmbHirKe6vdhKX7YSp+zUP0H9Od+lOhrx/VafJW2u/mKgKj3WqPQCDq4KL38QSmfuVBHB9LHUqXa7jJtVXdSKNhU3CI= Received: from BY5PR17CA0069.namprd17.prod.outlook.com (2603:10b6:a03:167::46) by MW3PR12MB4409.namprd12.prod.outlook.com (2603:10b6:303:2d::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9723.4; Thu, 12 Mar 2026 04:44:53 +0000 Received: from MWH0EPF000C6186.namprd02.prod.outlook.com (2603:10b6:a03:167:cafe::88) by BY5PR17CA0069.outlook.office365.com (2603:10b6:a03:167::46) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.26 via Frontend Transport; Thu, 12 Mar 2026 04:44:53 +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 MWH0EPF000C6186.mail.protection.outlook.com (10.167.249.118) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Thu, 12 Mar 2026 04:44:53 +0000 Received: from BLRKPRNAYAK.amd.com (10.180.168.240) 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.17; Wed, 11 Mar 2026 23:44:48 -0500 From: K Prateek Nayak To: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Valentin Schneider , CC: Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Chen Yu , Shrikanth Hegde , Li Chen , "Gautham R. Shenoy" , K Prateek Nayak Subject: [PATCH v4 0/9] sched/topology: Optimize sd->shared allocation Date: Thu, 12 Mar 2026 04:44:25 +0000 Message-ID: <20260312044434.1974-1-kprateek.nayak@amd.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MWH0EPF000C6186:EE_|MW3PR12MB4409:EE_ X-MS-Office365-Filtering-Correlation-Id: b6e3aeb7-8f25-40b7-2095-08de7ff21a33 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|1800799024|376014|7416014|82310400026|13003099007|18002099003|56012099003; X-Microsoft-Antispam-Message-Info: q6hy5tWGFLWFTTiVJw7B2JUO3bDxwlKx8APebUvBD6vzxgt/gClnYCDY1BxS31hqPT0+KWAfz3uaO94TXi4+wsalO/PZsC5ZKxkQeUne+RxUrTAoIjAgHQwdPXor/6h7P+XzLm6C3uLpK2ybJHEoMp/aTWjwuiH9A1c6s4ekl932yrrpku/IXIymwibxY7/Gje+s8eoFiV1LjrOlF1MH7nNZCAfTsX/f7JNMzHB5z5xPyGTa1j8yJ1zbh0XHEUwOTtgx0MwPVI+/0h8q7BylG7GAlL8ibVn+uQY1bVfJ0psuQl6wqdEcurcj5nOSsZsbr+c0GL4BbQIP03h3OUiq1t8GYjwOIEqkcqQQpYs70axtZdyuaQl/1ffvQoLvC9Zvj6giwn7pt6Yj51Atxn16TpJ2rG+w9u/rvoJJFKwgu916Zt6/BxmV5c7W57/KIFyfgiaKlNXKTQTyBYqNSEnhLaOtB9gOhyC7De+w/NU06LqCDFg8+DFrLk/aRV5GVyHR9K+GFqZstXG644y4LJdHuFYjP5Qexr0AGj2CpHfdbyBcBY+xke5nlHQ7IY1jakU7noFfkfyLUU0eW+N/wyYEOcK40Sbbgng4QTdzbUMd8BHYRs3sIybBuyYFWLQOoU8JP2i95fpqI8/uPfATWcMS6SIWb9JKCu+oDoQsYdmCZUvRjShvGwTV4LizkSYzws1n+h3bR3Hqck2PJ8ExagXOd32olQFdDVXSkkR+ufU7Kn8= 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)(36860700016)(1800799024)(376014)(7416014)(82310400026)(13003099007)(18002099003)(56012099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: RKWfPIs/06HVX6bkQqGIMGr9pckhuAcMS/VRXwngC2vT4xgFWwe0IRJoYwfd/4U2AgSHZO1RbdfvVzDGkoEUBTzRaQDtjZbuBhtKqHcc+T6pJgW2/Q/u+lchJMcN6c6iCBlSDIRxPh8vZCf10apziaJPemWI/g/1G6URfDx5oXXVtFR4FE2V5S4bMAoeC25Uou9oTqjWToocfi9Gy8ZfLQ4EMwGiiQd5Rb2Xevxf3oOZaNCVc42ow66OQYxounw2aGakv8ZjxDw8ClUp9d+GjwmmtuSj0IKhoPMhK7/k5sF4tQ8Pn6/MzYpq8jDpre2XDCl6I/wzjzapKA5xl7Os2hebTAxC/yMrhC2qk9tvgR/qTCea6Yz0jQCUg+SdOQ6yMkue74PtY0pNZ2j44IHq7hEDzIwI6KN8P5ZOFCYDIUvfC1fKJXikgxy88EMmGSrI X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Mar 2026 04:44:53.0204 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b6e3aeb7-8f25-40b7-2095-08de7ff21a33 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: MWH0EPF000C6186.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR12MB4409 Hello folks, I got distracted for a bit but here is v4 of the series with most of the feedback on v3 incorporated. Nothing much has changed but if you see anything you don't like, please let me know and we can discuss how to best address it. Background ========== Discussed at LPC'25, the allocation of per-CPU "sched_domain_shared" objects for each topology level was found to be unnecessary since only "sd_llc_shared" is ever used by the scheduler and rest is either reclaimed during __sdt_free() or remain allocated without any purpose. Folks are already optimizing for unnecessary sched domain allocations with commit f79c9aa446d6 ("x86/smpboot: avoid SMT domain attach/destroy if SMT is not enabled") removing the SMT level entirely on the x86 side when it is know that the domain will be degenerated anyways by the scheduler. New approach to sd->shared allocation ===================================== This goes one step ahead with the "sched_domain_shared" allocations by moving it out of "sd_data" which is allocated for every topology level and into "s_data" instead which is allocated once per partition. "sd->shared" is only allocated for the topmost SD_SHARE_LLC domain and the topology layer uses the sched domain degeneration path to pass the reference to the final "sd_llc" domain. Since degeneration of parent ensures 1:1 mapping between the span with the child, and the fact that SD_SHARE_LLC domains never overlap, degeneration of an SD_SAHRE_LLC domain either means its span is same as that of its child or that it only contains a single CPU making it redundant. Future work =========== This is an initial optimization for larger idea to break the global "nohz.idle_cpus_mask" into per-LLC chunks which would embed itself in "sd_llc_shared" and bloat the struct. Reducing the overhead of allocating "sched_domain_shared" now would benefit later by reducing the temporary memory pressure experience during sched domain rebuild. The suggestion to entirely remove per-CPU "sd_llc_shared" from Shrikanth has been deferred to this future work once few more users of "sd_llc_shared" in CONFIG_NO_HZ_COMON are converted over to use per-CPU "sd_nohz->shared" reference leaving only the {test,set}_idle_cores() using the per-CPU "sd_llc_shared" references. Misc cleanups ============= Since the topology layer also checks for the existence of a valid "sd->shared" when "sd_llc" is present, the handling of "sd_llc_shared" can also be simplified when a reference to "sd_llc" is already present in the scope (Patch 8 and Patch 9). Patches are based on top of: git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core at commit 54a66e431eea ("sched/headers: Inline raw_spin_rq_unlock()"). --- Changelog v3..v4: o Collected tags from Chenyu, Shrikanth, and Valentin (Thanks a ton for reviewing and testing v3) o Broke off the "imb_numa_nr" calculation into a separate helper to avoid having two "if" conditions - one searcing for sd_llc and other for sd_llc's parent. (Valentin) o Moved the claiming of "d.sds" objects into claim_allocations() to keep all those bits in one place. (Shrikanth) o Elaborated with a comment in Patch 9 on why dereferencing "sd->shared" in select_idle_cpu() since it's lifetime is tied to "sd_llc" dereferenced in the caller and as long as there exists a RCU protected reference to "sd", "sd->shared" is also valid. (Shrikanth) o Illustrated the problematic case highlighted in Patch 1 with an example. (Shrikanth) o Made a note of the larger optimization to "nohz.idle_cpus_mask" coming up in the cover latter that is helped along by this optimization. (Peter) o Rebase and more testing with hotplug and cpuset. v3: https://lore.kernel.org/lkml/20260120113246.27987-1-kprateek.nayak@amd.com/ Changelog rfc v2..v3: o Broke off the "sd->shared" assignment optimization into a separate series for easier review. o Spotted a case of incorrect calculation of load balancing periods in presence of cpuset partitions (Patch 1). o Broke off the single "sd->shared" assignment optimization patch into 3 parts for easier review (Patch 2 - Patch 4). The "Reviewed-by:" tag from Gautham was dropped as a result. o Building on recent effort from Peter to remove the superfluous usage of rcu_read_lock() in !preemptible() regions, Patch5 and Patch 6 cleans up the fair task's wakeup path before adding more cleanups in Patch 7 and Patch 8. o Dropped the RFC tag. v2: https://lore.kernel.org/lkml/20251208083602.31898-1-kprateek.nayak@amd.com/ --- K Prateek Nayak (9): sched/topology: Compute sd_weight considering cpuset partitions sched/topology: Extract "imb_numa_nr" calculation into a separate helper sched/topology: Allocate per-CPU sched_domain_shared in s_data sched/topology: Switch to assigning "sd->shared" from s_data sched/topology: Remove sched_domain_shared allocation with sd_data sched/core: Check for rcu_read_lock_any_held() in idle_get_state() sched/fair: Remove superfluous rcu_read_lock() in the wakeup path sched/fair: Simplify the entry condition for update_idle_cpu_scan() sched/fair: Simplify SIS_UTIL handling in select_idle_cpu() include/linux/sched/topology.h | 1 - kernel/sched/fair.c | 70 ++++----- kernel/sched/sched.h | 2 +- kernel/sched/topology.c | 263 +++++++++++++++++++++------------ 4 files changed, 199 insertions(+), 137 deletions(-) base-commit: 54a66e431eeacf23e1dc47cb3507f2d0c068aaf0 -- 2.34.1