From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from MW6PR02CU001.outbound.protection.outlook.com (mail-westus2azon11012019.outbound.protection.outlook.com [52.101.48.19]) (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 287D62EB87B for ; Mon, 16 Feb 2026 07:44:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.48.19 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771227883; cv=fail; b=Ep5ya6G59dUdpfW/oK0T1taxDaoN3DFui8p2BmteP2bA50aohLwtOFn0BIwwrCb+qPLFXGaVdU3c54sGnsGNh4nQOc2Y6zpaZQa1brMeda74NXPRmkxocFpsFvCu6s9ZYu6V2opK07Nxq6Q5vUaWoEDf9gmvpY7C3wtiMVQ73K4= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771227883; c=relaxed/simple; bh=nqjL6ZTWOM2YHnmSdV/jXXniGvCwank/8PI25mV3Xbk=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=I1EPcmlSVJRXsGt7eRUNvzVJqbC8UimN0Cizlcec70F4YcbFesWCOLD0UWU4OI7HCr6Lm903OSIUb4IJ6GDsAyP+jm7e3VNqDO3z5qukjMHAIeW+nI8HfmT8xB44hNeJCr/b+gWHQfI56g2YtxP8qDAXZx2ZoUM+N9NrCWpAM5U= 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=nsOaVT8a; arc=fail smtp.client-ip=52.101.48.19 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="nsOaVT8a" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=BCRNMplpvTl45FfJznJHlfIreVlqorUXShOaMHRINoAtti3g8QNIz9OMKKovR1y9yWeE2jTaDH+SeU219Xsf1El/igkmuSZsrDi0eDyb4koZskZBiJRaS/6CSLzbkE5j8G/h4i5RaL8cVd+wKwQ5CLOizcBfjZm5/Qxv7VhlDoV+GS91NPsWUdBQZGxzLCCYKOq/4Poz9SZd1FjFp9+WmA6OXLZT0h/W6/ToSr6yWhdlWXU0si6wTmvErBGSGj8EFcWFpcwfmU3gxAgBWhBCbk0pcLDaOMkkjzbIlpI8z1LdFEGfUtvEXb9EHK6/zWnFsLY7WipsGdfvqr1ToOWQmQ== 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=C2suCX2c288vw23p2JZRhhkUTsV9HBzkZij+5Vvg/kA=; b=q8yEJM80RTuJTvuA0+caVTzt9s4BC34g3OG7j0V2uG+l0BPpZVxDCTnLcLVPnnqoT3dilWhNlX+vpPO3NaJkFQK3LAvCDL6d1szfs38iUIcUuEoxyDblZp6qiu321RymNpGD7zXw/8ZtLUkMzfHn6Q/kg32iVFelq/dRy7YlP6cGX88uaSvxgUZyP36JiXB1DKef05mWIi9/hNy8gEpmCqA6b+fOA4qIKdc6MmzzLXL2GrfF+nGhU1pJwyLpr2HB8ZBK4DTQA7s4FLJCk1fFWWRvBwlC/Nl6DVqgV1eZknPf49F0Lg2m9H4Jq+PxzYlIwmAUyM6a4vYAfyOIZmOf4g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=linux.intel.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=C2suCX2c288vw23p2JZRhhkUTsV9HBzkZij+5Vvg/kA=; b=nsOaVT8aW9hKcCghl0BeLja8ezgq9E09sLx9FYNd8OfW3WpxFk+bQYH8sqNW7zK/dy+aLaU+Kn8iPL4V+kxGa4dcm3WbgCrOxMxqBj2X4Tntcr0Hb+526yGbUEC/VWqy0Ow7Mvi8qBbvScGlqWgbR6AKyWMyATd+cJBzmJwT67U= Received: from SA1P222CA0012.NAMP222.PROD.OUTLOOK.COM (2603:10b6:806:22c::16) by PH0PR12MB5680.namprd12.prod.outlook.com (2603:10b6:510:146::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9611.10; Mon, 16 Feb 2026 07:44:34 +0000 Received: from SA2PEPF0000150B.namprd04.prod.outlook.com (2603:10b6:806:22c:cafe::30) by SA1P222CA0012.outlook.office365.com (2603:10b6:806:22c::16) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9611.16 via Frontend Transport; Mon, 16 Feb 2026 07:44:32 +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 SA2PEPF0000150B.mail.protection.outlook.com (10.167.242.43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9632.12 via Frontend Transport; Mon, 16 Feb 2026 07:44:33 +0000 Received: from SATLEXMB04.amd.com (10.181.40.145) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.2562.17; Mon, 16 Feb 2026 01:44:33 -0600 Received: from satlexmb07.amd.com (10.181.42.216) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 16 Feb 2026 01:44:33 -0600 Received: from [10.136.47.100] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Mon, 16 Feb 2026 01:44:21 -0600 Message-ID: <79755f7d-cc68-4189-b6d8-850378e54017@amd.com> Date: Mon, 16 Feb 2026 13:14:20 +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 v3 04/21] sched/cache: Make LLC id continuous To: Tim Chen , Peter Zijlstra , Ingo Molnar , "Gautham R . Shenoy" , Vincent Guittot CC: Chen Yu , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , "Madadi Vineeth Reddy" , Hillf Danton , "Shrikanth Hegde" , Jianyong Wu , "Yangyu Chen" , Tingyin Duan , Vern Hao , Vern Hao , Len Brown , Aubrey Li , Zhao Liu , Chen Yu , Adam Li , Aaron Lu , Tim Chen , Josh Don , Gavin Guo , Qais Yousef , Libo Chen , References: <60a05a3f50d14a7bf3b968f62cca87893c5c552c.1770760558.git.tim.c.chen@linux.intel.com> Content-Language: en-US From: K Prateek Nayak In-Reply-To: <60a05a3f50d14a7bf3b968f62cca87893c5c552c.1770760558.git.tim.c.chen@linux.intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB04.amd.com: kprateek.nayak@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA2PEPF0000150B:EE_|PH0PR12MB5680:EE_ X-MS-Office365-Filtering-Correlation-Id: 7769a8a0-2f3b-4cb4-ac3d-08de6d2f3a1b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|32650700017|36860700013|1800799024|376014|7416014|82310400026|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?ZGJoWUxOZS9TSHNVZFFKbFc1SzlWcXEzSXRrbGVUNFVTdGcyTGo3YU5ZQUlM?= =?utf-8?B?VjQyUUwzeW53Z0lKSzhMTjBsOEl4R3hDbFF6bTErY0FQSUg4MWsvY0lZV2k5?= =?utf-8?B?Y3VUOTNEYUw1WExDUHAxSlBqZjQ3Yi9CaGxERGhZcWY4eGlkWEhER2wrMWN4?= =?utf-8?B?QnFGYWEzZnE3YXdDblZvV2JHSUNRRkVkak1EcUlucWtVdDRSV3hMZUlTb2Vk?= =?utf-8?B?ZTBGVnI5cTdvNi83bXR2NWJBNEhNOVJqdkVaYlBrNGpuMGNnRkpQUWl1YXR6?= =?utf-8?B?VXlmRmZWelNXYkZiamczTmFUcVhCRmU2WEdPbUZUcGtUK0lnZTk1UDg4TWVU?= =?utf-8?B?QTlLRkpud3d5ejZnRFFMeDFSYTg2UkZHaE9OZ090dmsrNVd3R1dNUjlkOUM2?= =?utf-8?B?cHlVVk5pRXFPNzhZci9VTFhTd3Y2QUJCYk1WR0pBQ0ZtNk5BR0lsMGxveWtN?= =?utf-8?B?ajBWU2RySlpyN29FV2pQZXhrYjRRM3pNbC9nNDNvc1NqbG5mSWRJNjNQSll4?= =?utf-8?B?ZThVTDdYczU3TVQvYlhTUmVrcjNJYllDWVliSHZFUVlUVjVuQWd3aUNabFdl?= =?utf-8?B?VU9yVEZONVNiWDNCUDBWbnphR2lZbFpHY1lTaml2SWllcmtnMCs3L1JUTWhS?= =?utf-8?B?UXhYdGJYMTQ1T3Q3NGV6Ui93TFlxRmVoQWdDV2Z3M3B5dTZnMW9hVTMwQW1B?= =?utf-8?B?cG9GRnkwY3hCcmhmNGo2Umk4YlI1OFZwOVJVWVhMVnNyM2RmZXNqbjQ1VUNN?= =?utf-8?B?czBURldEbnZMNXYvb0dtSnFWcU5jK3hCVExXcHYyaE81c1BTN0M2Q1V2N1Mv?= =?utf-8?B?TS9jTkVrbHdSL0FxK2M4LzNYU0l5NGxCbFZ1NnE4REtCRzZ4Tktkc2lUNEth?= =?utf-8?B?ZGx6MUsyc3RHQ2JOSFJQM3ExYzQ0NjdlbWZWVUxFd1dtbTV6MCthN3VtWnRo?= =?utf-8?B?czI3WDh5UjhhSFNGbGp4d1R0dmVOSHBYUm9KeDcyRDJzTW42VXd4YmRHVk56?= =?utf-8?B?K0kyaFZFVHZnQ1RqenRwcUsrSTdOTFpBSG9NTndJcldwNkdjNXRFb1RCUTZo?= =?utf-8?B?ZWtua3FoemcyeEdNM2pwOWlLY3FkKzBuczR4NWFTTHJZY0xQZE5hWUh2SnJv?= =?utf-8?B?Nll5TkpXUDdrcUlEd0kydGszUCttVldkS0ZzNE5xcW5aTzVjYngxTExpL1Ru?= =?utf-8?B?MUpPN3oxNlh1Y08rZEYwZE53U1RZeXJqSXFNanVmQ1FoZGlRZHc0WnUvcGVn?= =?utf-8?B?T2hpb3ZTbW1KWmFTanlYQm5URWNBODVhdXh0eXY5dklUMEo5ZmtjaEszY3Nk?= =?utf-8?B?d0t5by95bmF0S2VaNEhpWEVSeWRTT2lBcS9YZGdJenh3dEpOaS9uYzJBaHhx?= =?utf-8?B?NG54MjhzTXZIQkF0Qnhoa095ampyYnBsQituSXRHZ09BVnZjbTdtdG53b1Zz?= =?utf-8?B?ZzhZaWdaMWV5MDU1cThCbFFpbDNzVDBnQmFScmszdDFuZElTVHk5Y2VHQjg2?= =?utf-8?B?QmpIaWZQUVNEWHRXVmsvYkxaOUpjL2dWOXg0a3VrR0dEeldQZGhOUksrMXF6?= =?utf-8?B?QWhtbEY2UGZPOXFMVzRXYndYMTk0clQ0am51R3Yzcno3b1g5R0l5TGRManU1?= =?utf-8?B?WTQwamV5TXIrVHJMNERJVVpTR3I5dFRGaDZFSVhxMVlRaXdLelUvTjJqYld4?= =?utf-8?B?SEZUSmM1bDNZOTBudE5QQjJyNlYvbGROV204VWJHY3pYWGVNVFNHQUk4SEg0?= =?utf-8?B?cU5UVm1hNllrWkZSZENkenZlSUMybVRlekFJLzFjWTd0dTdIMHRtSm5HUjEv?= =?utf-8?B?ZW9SSXpQR2xzVnZ1MGFzd3QvMTJsZGpscWpLZTRJQlZINDdBNmZ4d3hkSnl3?= =?utf-8?B?bG5mUG1zLzBUQXBzSnU5YzltOW9GVTdxVVB4RDg5UU8zMVlWSzFKOUZpNTBs?= =?utf-8?B?bThVV2g2Qi9qblRUSUhMWDNINzNJRzZYOEJGd3orVGlMRXVzWHZ4ajF5M2h3?= =?utf-8?B?Yml1Y3lVbEZpZzl2Sk4yRGx5QXJMWGZGS3luVHpoQncxeVkzY3hkcEl3aDk0?= =?utf-8?B?eHVhY1hnRlh4Qll1ZEtqRERMWjVCcU4vM2QyZVZBL3VWWjBwUk45RStRR0s2?= =?utf-8?B?enhvMENlZkduaTR0Mk1wNDczQlBKaFhRcHdNNUxTZDMwQ0pnNllxTnJ2VGNt?= =?utf-8?B?OE53QnRuMWt6SHNQZHhZV2VOVEVhRy9zNTJSMm9vWXpNb0JvZXBYNWNray9T?= =?utf-8?B?Y203TWROV3NGakFSdEI4eCtiSFNBPT0=?= 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)(32650700017)(36860700013)(1800799024)(376014)(7416014)(82310400026)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: qqxP7DU3IkEPrKHywT7W4q01mBQMly3YArfgxd9M5aa3G/Z/MeeE3ZbFGKpRYL0Tal4+uDhf4l3lRoUTFUvAGkVXjy4U83WGNQLAMKHGRkJdD1tQCb9zubuQI7l1epTRHq4SZ6VG1RJYshbKisWP50wMG8jWcJMAEQZH7Uy+1AKV0OrfmpB8o3eNEptouwW5hZ/nGu4//PBF/sCYAVCJzcTvVs4mG8URCRXyx5p6dJhmv9rNNmugQk2zGpVj5o0sxBfsqLTkVJyfbOjH9uZlX06RG03pgsmUeVryREnQqp/2hgbtea1B1pCP08wsfWCUb5p6tKxxo1itsAV67HEQ0pw6DRFwGCuMU0GQCH7S8F903W/nXoTR7BKOX6EiiVqwWy/xiypy2p+b+lxDPTD9UYkEw8yK8pevucMemGV6pOcUOU/YA+g7QlFdPjmIeeAb X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2026 07:44:33.8339 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7769a8a0-2f3b-4cb4-ac3d-08de6d2f3a1b 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: SA2PEPF0000150B.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB5680 Hello Tim, Chenyu, On 2/11/2026 3:48 AM, Tim Chen wrote: > From: Chen Yu > > Introduce an index mapping between CPUs and their LLCs. This provides > a continuous per LLC index needed for cache-aware load balancing in > later patches. > > The existing per_cpu llc_id usually points to the first CPU of the > LLC domain, which is sparse and unsuitable as an array index. Using > llc_id directly would waste memory. > > With the new mapping, CPUs in the same LLC share a continuous id: > > per_cpu(llc_id, CPU=0...15) = 0 > per_cpu(llc_id, CPU=16...31) = 1 > per_cpu(llc_id, CPU=32...47) = 2 > ... > > Once a CPU has been assigned an llc_id, this ID persists even when > the CPU is taken offline and brought back online, which can facilitate > the management of the ID. > > Co-developed-by: Tim Chen > Signed-off-by: Tim Chen > Co-developed-by: K Prateek Nayak > Signed-off-by: K Prateek Nayak > Signed-off-by: Chen Yu > --- > > Notes: > v2->v3: > Allocate the LLC id according to the topology level data directly, rather > than calculating from the sched domain. This simplifies the code. > (Peter Zijlstra, K Prateek Nayak) > > kernel/sched/topology.c | 47 ++++++++++++++++++++++++++++++++++++++--- > 1 file changed, 44 insertions(+), 3 deletions(-) > > diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c > index cf643a5ddedd..ca46b5cf7f78 100644 > --- a/kernel/sched/topology.c > +++ b/kernel/sched/topology.c > @@ -20,6 +20,7 @@ void sched_domains_mutex_unlock(void) > /* Protected by sched_domains_mutex: */ > static cpumask_var_t sched_domains_tmpmask; > static cpumask_var_t sched_domains_tmpmask2; > +static int tl_max_llcs; > > static int __init sched_debug_setup(char *str) > { > @@ -658,7 +659,7 @@ static void destroy_sched_domains(struct sched_domain *sd) > */ > DEFINE_PER_CPU(struct sched_domain __rcu *, sd_llc); > DEFINE_PER_CPU(int, sd_llc_size); > -DEFINE_PER_CPU(int, sd_llc_id); > +DEFINE_PER_CPU(int, sd_llc_id) = -1; > DEFINE_PER_CPU(int, sd_share_id); > DEFINE_PER_CPU(struct sched_domain_shared __rcu *, sd_llc_shared); > DEFINE_PER_CPU(struct sched_domain __rcu *, sd_numa); > @@ -684,7 +685,6 @@ static void update_top_cache_domain(int cpu) > > rcu_assign_pointer(per_cpu(sd_llc, cpu), sd); > per_cpu(sd_llc_size, cpu) = size; > - per_cpu(sd_llc_id, cpu) = id; > rcu_assign_pointer(per_cpu(sd_llc_shared, cpu), sds); > > sd = lowest_flag_domain(cpu, SD_CLUSTER); > @@ -2567,10 +2567,18 @@ build_sched_domains(const struct cpumask *cpu_map, struct sched_domain_attr *att > > /* Set up domains for CPUs specified by the cpu_map: */ > for_each_cpu(i, cpu_map) { > - struct sched_domain_topology_level *tl; > + struct sched_domain_topology_level *tl, *tl_llc = NULL; > + int lid; > > sd = NULL; > for_each_sd_topology(tl) { > + int flags = 0; > + > + if (tl->sd_flags) > + flags = (*tl->sd_flags)(); > + > + if (flags & SD_SHARE_LLC) > + tl_llc = tl; nit. This loop breaks out when sched_domain_span(sd) covers the entire cpu_map and it might have not reached the topmost SD_SHARE_LLC domain yet. Is that cause for any concern? > > sd = build_sched_domain(tl, cpu_map, attr, sd, i); > > @@ -2581,6 +2589,39 @@ build_sched_domains(const struct cpumask *cpu_map, struct sched_domain_attr *att > if (cpumask_equal(cpu_map, sched_domain_span(sd))) > break; > } > + > + lid = per_cpu(sd_llc_id, i); > + if (lid == -1) { > + int j; > + > + /* > + * Assign the llc_id to the CPUs that do not > + * have an LLC. > + */ > + if (!tl_llc) { > + per_cpu(sd_llc_id, i) = tl_max_llcs++; > + > + continue; > + } > + > + /* try to reuse the llc_id of its siblings */ > + for_each_cpu(j, tl_llc->mask(tl_llc, i)) { My only large concern that remains is the fact that offline CPUs are taken out the the tl->mask() which can lead to interesting cases where CPUs on same LLC can have different llc_id: o Boot with maxcpus=1 o Run: for i in {1..$NRCPUS}; do echo 1 > /sys/devices/system/cpu/cpu$i/online; echo 0 > /sys/devices/system/cpu/cpu$i/online; done o Finally run: echo 1 | tee /sys/devices/system/cpu/cpu*/online; Once all CPUs are online, only the CPUs in boot CPU's LLC will have the same llc_id. Every other CPU will have a unique llc_id which might make the system behave unexpectedly. I'm wondering if we can do something like below on top of this patch: (Only build tested; Prepared on top of this patch in Tim's tree) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index c6efa71cf500..aee1be89ab4c 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -8268,6 +8268,8 @@ static void cpuset_cpu_active(void) static void cpuset_cpu_inactive(unsigned int cpu) { if (!cpuhp_tasks_frozen) { + /* XXX: Is this the right spot? */ + sched_domains_free_llc_id(cpu); cpuset_update_active_cpus(); } else { num_cpus_frozen++; diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index de5b701c3950..31a8910297c7 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -3903,6 +3903,7 @@ static inline bool sched_cache_enabled(void) } #endif extern void init_sched_mm(struct task_struct *p); +void sched_domains_free_llc_id(int cpu); extern u64 avg_vruntime(struct cfs_rq *cfs_rq); extern int entity_eligible(struct cfs_rq *cfs_rq, struct sched_entity *se); diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c index ca46b5cf7f78..04c1ab489ee2 100644 --- a/kernel/sched/topology.c +++ b/kernel/sched/topology.c @@ -18,6 +18,7 @@ void sched_domains_mutex_unlock(void) } /* Protected by sched_domains_mutex: */ +static cpumask_var_t sched_domains_llc_id_allocmask; static cpumask_var_t sched_domains_tmpmask; static cpumask_var_t sched_domains_tmpmask2; static int tl_max_llcs; @@ -2543,6 +2544,53 @@ static bool topology_span_sane(const struct cpumask *cpu_map) return true; } +static int __sched_domains_alloc_llc_id(void) +{ + int lid; + + lockdep_assert_held(&sched_domains_mutex); + + lid = cpumask_first_zero(sched_domains_llc_id_allocmask); + if (lid >= tl_max_llcs) + tl_max_llcs++; + + /* + * llc_id space should never grow larger than the + * possible number of CPUs in the system. + */ + if (!unlikely(WARN_ON_ONCE(lid >= nr_cpumask_bits))) + cpumask_set_cpu(lid, sched_domains_llc_id_allocmask); + return lid; +} + +static void __sched_domains_free_llc_id(int cpu) +{ + int i, lid; + + lockdep_assert_held(&sched_domains_mutex); + + lid = per_cpu(sd_llc_id, cpu); + if (lid == -1) + return; + + per_cpu(sd_llc_id, cpu) = -1; + + for_each_online_cpu(i) { + /* An online CPU owns the llc_id. */ + if (per_cpu(sd_llc_id, i) == lid) + return; + } + + cpumask_clear_cpu(lid, sched_domains_llc_id_allocmask); +} + +void sched_domains_free_llc_id(int cpu) +{ + sched_domains_mutex_lock(); + __sched_domains_free_llc_id(cpu); + sched_domains_mutex_unlock(); +} + /* * Build sched domains for a given set of CPUs and attach the sched domains * to the individual CPUs @@ -2599,7 +2647,7 @@ build_sched_domains(const struct cpumask *cpu_map, struct sched_domain_attr *att * have an LLC. */ if (!tl_llc) { - per_cpu(sd_llc_id, i) = tl_max_llcs++; + per_cpu(sd_llc_id, i) = __sched_domains_alloc_llc_id(); continue; } @@ -2620,7 +2668,7 @@ build_sched_domains(const struct cpumask *cpu_map, struct sched_domain_attr *att /* a new LLC is detected */ if (lid == -1) - per_cpu(sd_llc_id, i) = tl_max_llcs++; + per_cpu(sd_llc_id, i) = __sched_domains_alloc_llc_id(); } } @@ -2798,6 +2846,7 @@ int __init sched_init_domains(const struct cpumask *cpu_map) { int err; + zalloc_cpumask_var(&sched_domains_llc_id_allocmask, GFP_KERNEL); zalloc_cpumask_var(&sched_domains_tmpmask, GFP_KERNEL); zalloc_cpumask_var(&sched_domains_tmpmask2, GFP_KERNEL); zalloc_cpumask_var(&fallback_doms, GFP_KERNEL); --- It doesn't compact tl_max_llcs, but it should promote reuse of llc_id if all CPUs of a LLC go offline. I know it is a ridiculous scenario but it is possible nonetheless. I'll let Peter and Valentin be the judge of additional space and complexity needed for these bits :-) > + if (i == j) > + continue; > + > + lid = per_cpu(sd_llc_id, j); > + > + if (lid != -1) { > + per_cpu(sd_llc_id, i) = lid; > + > + break; > + } > + } > + > + /* a new LLC is detected */ > + if (lid == -1) > + per_cpu(sd_llc_id, i) = tl_max_llcs++; > + } > } > > if (WARN_ON(!topology_span_sane(cpu_map))) -- Thanks and Regards, Prateek