From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazon11012008.outbound.protection.outlook.com [40.107.200.8]) (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 A22EB946A; Sat, 21 Mar 2026 15:15:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.107.200.8 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774106109; cv=fail; b=lzgenTEZPf3y7RtDu76CcIqC9GZXtPqM3yZWUWHhHVvq8wlqVQNVvl3vJFB5EwxvIZqt8+IQVP/KDlIDewahNISL0QtQZZVXKKs7cY+Odpj6MreAP8OEukrjVJxteOYCahnqg2LGQWgsxughIjMXMrYmmozzjPcVt7QOl+fV9VY= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774106109; c=relaxed/simple; bh=wQBDq5NWSWX0Ct289l4cgYp43fykErcT5wjnK/xXWqc=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=iSBQk0eJ46w4JhR5ZeUoFLQOK4oUne4UyayYsFFV1DJ5+tRgDoAEr4RDkhsrIJaby4B/TQpB62frFefJA/bKCjFTML/KCYNTk2H0kFMl+xcwrRPAVsClFmjPSikp0mpdiJDVYCYcx6rFHYje5CJlcggM9382Qg3YQSehMbEAZdo= 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=5FKo9jgO; arc=fail smtp.client-ip=40.107.200.8 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="5FKo9jgO" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=i9MsS8ohnPbj73ftkna/t4gnOxzh3aPaP27kjqAlcv/LGM1wraajkpS5KiS/Rm85pk5ExCuqudJK8PBbvOFOC/4jmAahp27L+GsBYxvmTBMDgi8Yd79ybkL5WXnCLLQQEzRwkrkPwTdqx2pozYnx03W7gELOngg4zMCKG99cDy4eSdYjJOYMW72Rcgz6cKwkjLyI/DNnhQFMgKt22r11fgsM3a5ODM/s0/VN+qIvceGZbGYNpZqul51gaa9IHQXXpcBGaN68OwjyZFGtwugCLyVyOcbS/XA7w63k0TJjI1TWKoff2KttbKewsAs1IfMfm+IuR//b38YUSdLXUGq1yg== 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=HA6VEWIvoIYS91kzEU01qXk2P28lHMlPXFRlHjHKMDA=; b=K1+CYwfu9ITGsohEVvccagv4w0Mch6Bnp6t3ST+ijsAL2oujqM0tNtxJoeKx8pzitU/nW2T/gXj8wL0iNQyn1AZi7QELD3ZvOKTmZYkSFq3TRuYkhTT4EE7PG+Cez2KuBK3nae261XWn9AkvyKrBb6rdQTNwxO0mX9x/8Dd8RGNl6KAqad6uxPob+ZU1jJByWGmrcHL5HMJFKQyV83XeWkg0OHHqDvL91Ry+ukfe7MogrIMjMgDPxHnA8Hs5HIY9b/MmuVmlG/zqrOOEoq0dq/xUf2ahMDGI/aeIj8znAog2HT1EKtm3jMy0TzXh1Y3G4MBJFcC+OoMO+raGf610bg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=linux.ibm.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=HA6VEWIvoIYS91kzEU01qXk2P28lHMlPXFRlHjHKMDA=; b=5FKo9jgOVOPbH8NR2uzHtNYLO0rezVAY+JlwkXgrOoxe8oMovSGhI8HTBgHVBf6G4JNueNmv5Pjk/tqH7ttjDTEVf3s0zy2iQubTIZqqF0Doe7qC/GDNFmuPpj+UdfgHPSt33w+MV2e6oZKpWmSYp1rMFjxyAxt4ilbPPPeI+LI= Received: from SJ0PR13CA0195.namprd13.prod.outlook.com (2603:10b6:a03:2c3::20) by MW3PR12MB4364.namprd12.prod.outlook.com (2603:10b6:303:5c::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9745.15; Sat, 21 Mar 2026 15:15:03 +0000 Received: from MWH0EPF000C6186.namprd02.prod.outlook.com (2603:10b6:a03:2c3:cafe::e5) by SJ0PR13CA0195.outlook.office365.com (2603:10b6:a03:2c3::20) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9723.25 via Frontend Transport; Sat, 21 Mar 2026 15:15:02 +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.9723.19 via Frontend Transport; Sat, 21 Mar 2026 15:15:02 +0000 Received: from Satlexmb09.amd.com (10.181.42.218) 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; Sat, 21 Mar 2026 10:14:59 -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; Sat, 21 Mar 2026 08:14:59 -0700 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.17 via Frontend Transport; Sat, 21 Mar 2026 10:14:57 -0500 Message-ID: <5f54f442-8304-4cd0-af6f-78fd0fb74e6a@amd.com> Date: Sat, 21 Mar 2026 20:44:56 +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: [tip: sched/core] sched/topology: Compute sd_weight considering cpuset partitions To: Shrikanth Hegde , Peter Zijlstra , "Chen, Yu C" CC: , , Valentin Schneider , Dietmar Eggemann , , Nathan Chancellor References: <20260312044434.1974-2-kprateek.nayak@amd.com> <177382132440.1647592.1849180094328011054.tip-bot2@tip-bot2> <20260320235824.GA1176840@ax162> <60406550-d90e-4efa-a4d9-f901421887f8@intel.com> <470ce693-ee2e-414e-930b-d6581d649110@intel.com> <7fad91ea-e6cd-43c8-abe3-16d7843247ed@amd.com> <10204982-a007-4f44-ab12-bcddfe4140c8@amd.com> Content-Language: en-US From: K Prateek Nayak In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MWH0EPF000C6186:EE_|MW3PR12MB4364:EE_ X-MS-Office365-Filtering-Correlation-Id: 7a6f24fb-a591-4f2f-e471-08de875ca01c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|82310400026|1800799024|376014|13003099007|22082099003|18002099003|56012099003; X-Microsoft-Antispam-Message-Info: kkETTz4I2F5Zkc6cJVyUWI/KeiFs4PIEl0VCV1IjQu/ZOFRS3PXk2RDZVULJJi08ot27HsaOFjdDAt6Q9c3NrBPZYiC4YjGrHomSg4UpwvcTMzponADvdbhI0m2bclqWtSI2SIQrX0WX9P8j6X0sjdZmxUQlID638icXSmY/nvAgYU5oNmEnfWRlCtb29X3xQR6PZnfKK23fBYFafjSmSt9h4hpb7gMjOGrtt07eYbxIGkUCCwivcfeLmPZsfqxBru6z6Jow0EFIf6amHwDDaNAXevl9WOGNrFZ9Oso4ZP652WSGf/kWAwiPdUJ1aKnrvbhsbrunAPnk+hocdecERXCemK59dRhQQlCvG3vwf0TjPR4YBOG5aanLsKCBI2lIyWU7CbsyS1LImHhRYrcoNXtpOblMrvWPyP8FNOS3gqLawlJKqOkbPyDGAK0zrUSsBU8GuXCCaRqcb62KV3/lZwDgRWn1GvLz3W955qu3M9zg5rZlbStq4TvDXRnYFjtvLXxEHXMlDQolGSbMeDa8PAXh4Wnh/tKrmSlzPkwhvgm7cifvh0c7veE9+OVqY+adW1ACEDB0I07q8YQwc9xBfRsB8Vj0s399/doaLRA980RVc0Hw59kbFLBB8Xd7PB66hnjxfxeOFo2b9EVkHvlQ9hUWw1BXjcWcUfB/oAxgq9FUhiUjb3kPik4jZcSsJpUWc0Lx7P1E96TbC6kQ6ckyapTFU8Qjng6+gtaTJl5CI25Ljfk9nS8QgToKjD/EMS+VJqjInVclaDCxc+TTcq9mfg== 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)(82310400026)(1800799024)(376014)(13003099007)(22082099003)(18002099003)(56012099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: hjbRP9cgArWgKGW3Qk7UDFY2+kAmC++/qhRVPsKpMRZQYLcEF32rlBLjhZEUuqt5fqPZdEezkjJVCOqxRXGnb7RpAUxyIsTf4z29AOr0bDoeXpB2V8jFzcdtvwgLnqFGpwLAZ3tmmXeA9pmYPtWIeyDUglPyJIMqn1j0/NO+AGVuNSpcd2Ig1VL5ps4W51mbJE/3BAalXbS/m9e0dmh+xvXoc5JjdpOrP7hUItUJ1Krjy2/NxEp4XPD31S5kIPajs4Budtnf0dUaDmpNua71u+X8n1IJ/8i32ZBN9O3pIWY1cnAhPBo1dcgzWrGhcgnoCbbCV2b8uZCN15pvavZiT02DT7XkbeS48AN2rc542gTaHEmFP1p04sC11u/h0Nk3DunH+2ZpI1pUMG3Uzi2Z+ByEDjLe0RvNdG4tkM/zpzW2Zoy0b308lz4vjzk62GAR X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Mar 2026 15:15:02.4830 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7a6f24fb-a591-4f2f-e471-08de875ca01c 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: MW3PR12MB4364 Hello Shrikanth, On 3/21/2026 7:43 PM, Shrikanth Hegde wrote: >> And more evidence - by default we have: >> >>    sched_domain size: 296 >>    offset of sd_span: 292 >> >> sizeof() seems to account some sort of 4-byte padding for the struct which >> pushes the offset of sd->span into the struct size. >> >> To resolve this, we can also do: >> >> diff --git a/include/linux/sched/topology.h b/include/linux/sched/topology.h >> index a1e1032426dc..48bea2f7f750 100644 >> --- a/include/linux/sched/topology.h >> +++ b/include/linux/sched/topology.h >> @@ -148,7 +148,7 @@ struct sched_domain { >>        * by attaching extra space to the end of the structure, >>        * depending on how many CPUs the kernel has booted up with) >>        */ >> -    unsigned long span[]; >> +    unsigned long span[] __aligned(2 * sizeof(int)); >>   }; > > Wouldn't that be susceptible to change in sched_domain somewhere in between? > Right now, it maybe aligning to 296 since it is 8 byte aligned. > > But lets say someone adds a new int in between. Then size of sched_domain would be 300. > but span would still be 296 since it 8 bit aligned? So the official GCC specification for "Arrays of Length Zero" [1] says: Although the size of a zero-length array is zero, an array member of this kind may increase the size of the enclosing type as a result of tail padding. so you can either have: struct sched_domain { ... unsigned int span_length; /* 288 4 */ unsigned long span[]; /* 292 0 */ /* XXX 4 byte tail padding */ /* size: 296 */ } or: struct sched_domain { ... unsigned int span_length; /* 288 4 */ /* XXX 4 bytes hole, try to pack */ unsigned long span[]; /* 296 0 */ /* size: 296 */ } If the variable length array is aligned, there is no need for a tail padding and in both cases, length of span[] is always 0. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html But ... > >>     static inline struct cpumask *sched_domain_span(struct sched_domain *sd) >> --- >> >> and the kernel boots fine with the sd_span offset aligned with >> sched_domain struct size: >> >>    sched_domain size: 296 >>    offset of sd_span: 296 >> >> >> So Peter, which solution do you prefer? >> >> 1. Doing cpumask_and() after the *sd = { ... } initialization. (or) >> >> 2. Align sd->span to an 8-byte boundary. >> > > Only update sd_weight and leave everything as it was earlier? > > sd_weight = cpumask_and_weight(cpu_map, tl->mask(tl, cpu)); ... I agree with you and Chenyu, that this approach is better since padding and alignment is again dependent on the compiler. Anyhow we do a cpumask_weight() for sd_weight, and cpumask_and_weight() being the same complexity shouldn't add any more overhead. While we are at it, we can also remove that "sd->span_weight" assignment before the build_sched_groups() loop since we already have it here. -- Thanks and Regards, Prateek