From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.17]) (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 5BCF71C4A20 for ; Tue, 17 Feb 2026 06:07:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=198.175.65.17 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771308474; cv=fail; b=R4XIy3XcYIWTpOkk8/LzYq39OYbjmGsvqOFv1C7MG+VajyDTiPV0pZqYZPadiSChidMyFgX6pFnow//EMc55NWf3asJULS7rrIe7Ioo1NFIeMk65P0Y1QNg6i21jrvoFDwcgvbDuj8bth/x6dYOsHh/bdaP6sFrc6Zq59bE+zXs= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771308474; c=relaxed/simple; bh=JPkDqTMkr2n+VjgSO9Xy+Qom+LtWE4e9N5RRMfnVKVI=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=UU41pcrt4rNBC3tGXhrnLToW2sRMfQVHJr0siGREXl7dZ2oUeREaHcfDssAXLm5b7w54dV1B4n9PNi80dcXVPKBMfbH6IuFKUxIjkg00tUU13WQ9gW6bVPStN5wd2Ncx5gD/NIjwwBB27TbhRoaLfEQF6n27LKXw37rI8PFJjqk= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=iDXpRUqg; arc=fail smtp.client-ip=198.175.65.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="iDXpRUqg" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1771308473; x=1802844473; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=JPkDqTMkr2n+VjgSO9Xy+Qom+LtWE4e9N5RRMfnVKVI=; b=iDXpRUqgrE69nqzCQ3WFffnbmS6AXxNTAtOgcLr9k8IsZB0Vl+kHBiXX AtrGp0t8Q2pXFdUw/DDQJhl78a4Uv0mBg581qNEq+hCtyUI9adNS2Y37J RoHWZCd3Jg0FboT+Gv8i/i4BXV6aYadJaQkOu7AOOOk0t4Z12f6WBq+3M ETqIyhfd8JG2qe4X92MPb8+5LCCkjCKiOIQZvmWOc7U89565FKSZEYJ4b KrCpNPlZJxFYf83EPqOZ3UVIhgkXrfXMOUGHjeKE0X1sHCBY4c1hYkb7D YlFTcWVM9FNxfBBzkYXjivhqO9hqT4kjkD0TT6Q4jbv6VbvdvEzOtXhjZ g==; X-CSE-ConnectionGUID: TdZpN7iuRy+1DGqeDpBUCA== X-CSE-MsgGUID: 5Hm8Mub7QGG5vcZ/gJja7Q== X-IronPort-AV: E=McAfee;i="6800,10657,11703"; a="72367162" X-IronPort-AV: E=Sophos;i="6.21,295,1763452800"; d="scan'208";a="72367162" Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Feb 2026 22:07:52 -0800 X-CSE-ConnectionGUID: PtiIqTzBSlOvbfNsS2aEzA== X-CSE-MsgGUID: kVVYt80KS8qQBO9BOgFJdw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,295,1763452800"; d="scan'208";a="217751938" Received: from fmsmsx902.amr.corp.intel.com ([10.18.126.91]) by fmviesa004.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Feb 2026 22:07:52 -0800 Received: from FMSMSX901.amr.corp.intel.com (10.18.126.90) by fmsmsx902.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.35; Mon, 16 Feb 2026 22:07:51 -0800 Received: from fmsedg902.ED.cps.intel.com (10.1.192.144) by FMSMSX901.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.35 via Frontend Transport; Mon, 16 Feb 2026 22:07:51 -0800 Received: from BL0PR03CU003.outbound.protection.outlook.com (52.101.53.70) by edgegateway.intel.com (192.55.55.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.35; Mon, 16 Feb 2026 22:07:51 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=R8AaX50XfV8/THqyxwQhMcyqApx3b2LfjHJvvzOeNXFpVZUa5oT32Dk5djC7YmqXxnA9MXBVqoeo4ftspDS9YHaEx2hJ9QqNwAAxX7qu4iwIz8STU9xQ0HDfHgNXnaS3KwyHOZsdHv0LbuOOTmhdE4xo2kWMUagVzdnamzbRoUb4LG+7qRyyjD0tCaibCLnyFA4IKkDJp9l0R+ApSIYTPaewpYcer5iWy5Pi+00ROFePKHWbM9vxiOOTddZPDdERZkn1QY0SIIZ9z0OHkDXOlzGRAw6UtH8Iy5oYA+pRBOQqbpu6LM+SFSUh2OgtkAW2t9rjHrJmgUsy0HWBBHe6Xw== 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=8Km/os707wACg7vz89Ya6r67myOB5wc0gPUK46Ir9A0=; b=jZnTsiM4+2nf3UrOjIX5R2IOZSgtxScVPYyptU6Jl46jUZB5lzavCWY9ENfgnnszD9XeBPkaxakh3EwMamLFi7yj6S0POrcqbKeBAnEMFBu0TRAVTMfa6Upp1kHcj+Ba3o/KBl6NKH5PooMaqTW9d8QvPLPfkSTxxg/cJBu1Zl//uTvaq1aaOSfmYj0HUW0fxAMsz/8GPtrPkLfsqJ1Jnu0FGd43LnJ7v/YbPHU8+NLbvnA21Faprf+uGvll3aSuyE3VlqkCBWWaqrQwkaHDweISGafLFPHVBIwMbkvGlur22I9KhKDkoFGAp/ARBZ7BTR3wOurzqQ+47/ZwhDJu1A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from DM4PR11MB6020.namprd11.prod.outlook.com (2603:10b6:8:61::19) by SAVPR11MB9549.namprd11.prod.outlook.com (2603:10b6:806:4e9::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9611.16; Tue, 17 Feb 2026 06:07:47 +0000 Received: from DM4PR11MB6020.namprd11.prod.outlook.com ([fe80::3058:1480:e4ac:5765]) by DM4PR11MB6020.namprd11.prod.outlook.com ([fe80::3058:1480:e4ac:5765%6]) with mapi id 15.20.9611.013; Tue, 17 Feb 2026 06:07:47 +0000 Message-ID: <95923e36-4117-4209-97aa-a92b60f2bd49@intel.com> Date: Tue, 17 Feb 2026 14:07:22 +0800 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 04/21] sched/cache: Make LLC id continuous To: K Prateek Nayak CC: 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 , , Tim Chen , "Peter Zijlstra" , "Gautham R . Shenoy" , Vincent Guittot , "Ingo Molnar" References: <60a05a3f50d14a7bf3b968f62cca87893c5c552c.1770760558.git.tim.c.chen@linux.intel.com> <79755f7d-cc68-4189-b6d8-850378e54017@amd.com> Content-Language: en-US From: "Chen, Yu C" In-Reply-To: <79755f7d-cc68-4189-b6d8-850378e54017@amd.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SI1PR02CA0044.apcprd02.prod.outlook.com (2603:1096:4:1f6::6) To DM4PR11MB6020.namprd11.prod.outlook.com (2603:10b6:8:61::19) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM4PR11MB6020:EE_|SAVPR11MB9549:EE_ X-MS-Office365-Filtering-Correlation-Id: c22b07e5-01ef-463d-e476-08de6deadf50 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|7416014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?Mk1yRXZLOStiVnpybXFKUzBYa3V2enRVL0hjdS9kcGRLQVBMWUM4TmwwTmtv?= =?utf-8?B?RUtzM3lxRVNKZlRnaUo4b3Bjc3NycjUwRENDMytLU1QzcUhZL1JpWm1HbW4y?= =?utf-8?B?aWE3Q0djZGJWTWY4N3dzckFYUE94cm5xWUY5TEgzd0dwNGdGSU9HQTFsUTVh?= =?utf-8?B?V3VHdjhFSjZFazNqNzlhNzBQWVhYOTZDREZwdkRJMmdMYWFQY2U4TWhCSU5y?= =?utf-8?B?ZWRvMUloM0lJaUxwUXRtTnNNakkrM0JyL2VMTFNYQlp2S3phenNCWElhNUww?= =?utf-8?B?ejhMZUw1aXBuYStYbVdhSEd4NmlTV2Z0aEZLUnV0aDlvcno1ckw5ZXlPNktM?= =?utf-8?B?MllxNXlYeUdiZ0s2MlFhZ1RKTWRMcm9aRmR5K2doOTM1RzNlQ0R0OUs1bjVa?= =?utf-8?B?MldaSzNZUWZHenROYW55b3hrTGlnazQ0bVIwUkF3UHliWHZoaHFzT28zSjlp?= =?utf-8?B?U20rSzJ5NVQ0dEdISUZvazI3WnlHS3ZLSUJJNjVYZEphYTZzbmE0R3JxdERU?= =?utf-8?B?cERxbHE1Q0VmbDZIeUx5NXRzQisxOTIwMXFPcVB1VnZwZ3ZkSWZFTFpVdXp5?= =?utf-8?B?TXJvNC9WTTNaa0NzeHZab25acGxBWTVUd1ErSjdXSVpDeVppVmNkZ0d6eUhX?= =?utf-8?B?QjhPYVRGKzUxL0Z5a0VPbjVIRGNaMU9QSitya3RMcnVlWWRaQXdmSHc2UnVh?= =?utf-8?B?d1FUN0NsQkFJZzZEaGVmOVMwRTNISGVlaytHYVR0VDAzNUg4R2w1RXJvYzY4?= =?utf-8?B?emRTRjEwOVJYd05PUkwrVWRTOEVaMVV4Y3FaTlYvdUhyQTJNTzhNNGk3UFkx?= =?utf-8?B?WHZmYVNtQ0QwK2UyK094QUNzZ2h4QVBLbk9mbkpWYTJSWi9EVDBoemJ0eDVV?= =?utf-8?B?T0pQMXdwaWFMb2xZTkJMNjZVUjFBYnludXorOGVha1V3SzFCSmtwVFd6cGpK?= =?utf-8?B?RVFaYWJQazMxcUQ2NS9ac3ZpNHhhV0ZBeXlraWx6ZG5yTUZGa2c1MnJ5ejFK?= =?utf-8?B?OTBaNlZOaTM2ZEczVW9DUUNPOEo1cUtaVHU3UmJuQ3ZOR2xFQU1XTXBKZ3pz?= =?utf-8?B?cjF3czk2Sno1VGdXbzl2YVdSUVYzUkwzcnJ4QlZTSXFkcGlJUlJESWhYdGpC?= =?utf-8?B?eFU0MFd3MUZlaDd5VUxPQjBjRURaYmU0NkFZMGhMdFdIaHkwd0l3d2dIQzNX?= =?utf-8?B?QW8yVlJWdlk3NTJZUTN6bmtIVE85cDZnVEczWjhJZmJlTVJRcW5EeG1TMnpt?= =?utf-8?B?RFNtRTBXSW8wMzA1eGphZ3RiSWd6V3JrNnFTKzZ0eGhjV1l2WEJhMjh6ZVZy?= =?utf-8?B?UHYzTjczVEwyODZIUVQwNkNqcHFkOVoxOHR4NjkyL0xyd2Z4MnBaM2VnV0Fo?= =?utf-8?B?N2tNODlUeUtIMU9kNmRNaThjOEhocFNlVXpVeVBvRWpBT1puUGNNSDZNUnlU?= =?utf-8?B?UmJoaUxaQ1VQUmFleExrb1dUdjhESlRlcHdmY1lERTlxK2FjWno4Tm5LRlNr?= =?utf-8?B?NW1TYnJucGJaSG9DUnpyYXphV053eUU2VXFWYkN5WFhvaTZZb3ZDZk82a1Fn?= =?utf-8?B?WE9RSmtCTllTTjYwTDBKbEhhK3IrMFp5aDVCNWQ5K01jUnBVejI1dmxkWlN0?= =?utf-8?B?eGM4QUJrSGpqMkE5VEV4cVJaNTVBaWNlZnRsRjVqaXhpMXNvNXYraktoNDBn?= =?utf-8?B?WjdST2w2cHJ1VFF5NDZYMnVQSWNTdmxoRjB1SUFSTXJFcDF3bExKL0dYbEhi?= =?utf-8?B?by9YOEU2SkQ1b0lTV2pxayt5c2ZQcHM2U0dZdXZzQWhNemx4WC94V3BqUXVa?= =?utf-8?B?SmhYS0ptVkZHWGN3d0YrWmFsYnpBYWJaTDhsYWwzaEhlM0FSZFQ2UzJtbGNI?= =?utf-8?B?WW9LT2tJc21NdlhzSGtFWmJ4SFl1K2QvUXlFbXE1RHcremlDVG5nRis0ZjA1?= =?utf-8?B?WFYrTVFBZW85KzgzMFBzaXRNUXpYQW5Dc1dPNS9HeElKSEliSWRIaFdrZm1G?= =?utf-8?B?bHY4UzdSRjlEOVpPQkZaNzhpb09FcFlUYm9RT3pyWi9tRktidTViSU5yKzFE?= =?utf-8?B?bzNMN0lTN1VXSlpUdXR6YnQxZUFBQlJyanh4Z2FpcXl3bWFmWGlIejlDUGtV?= =?utf-8?Q?L4uM=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR11MB6020.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7416014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cFRFQWVBODZndzlxeUFON09sOVRtaVBzenZnK202dUJSbTJ2RTM1ejJwZkxR?= =?utf-8?B?dHZlSG96L3J3YzM4cElOZE5iOHpOdTdNS1BPTmlNUUZvMm0xU0VhclRWVTcv?= =?utf-8?B?U01OeUoveHlxQ2xBek9pN1BINE96Y3lWRnNyMVduL1YxM2dhQjB6RlBjelI3?= =?utf-8?B?N1kxc1NJS1Z0MzNkZVlsZXZ3MFlnZjVObVp6Y1Bidy9obkE0aTFXazZ4Q0g1?= =?utf-8?B?eVJIUTdURUc1eFJvY3VTNlg4MDFEQVZNVUZxMFNtdEVqeHVDOEFjdTNLQlFm?= =?utf-8?B?MkdDWkJUMk8yZDkwLzFOQkVCYjJxMXBpenJzYW9lWXJpampvb2ZKQUFiMlUr?= =?utf-8?B?TXRuU2dvKy90R1hyYTdGR3dqclJyM0FtZ003a1dIdi9yU1MvMDlEaTQ3cG5F?= =?utf-8?B?Wjd5bU1HVGVQOTVBbFdwSm5zQXVWd3puL1cwQU42VUJUWVhNUk1nbU1Qell5?= =?utf-8?B?cHBvbmQxSzhIeEpQaVl3TVQrbWVxeVRpKzZHZndsVU5oZlhrTEJEVnRpSWVO?= =?utf-8?B?aThCOWJjK0FIKzJWMXFQNTNNMUhiS1B1V25QeHUxd1FHSkJESGNHVU8vcnM4?= =?utf-8?B?ZFdjMEVmNEZSU0RDK0NHbTdUQkJBREJtRzcyRmlXM2Q4QkUvbWFaMTdURTFB?= =?utf-8?B?ZXk0WmFFZXBsMzByWXo1YzdkZG90NnAvRXNuNHdPZ1U5Mm9jTjZ5OHJRZzVx?= =?utf-8?B?Y3RHc2l3K3dCdWFlMUt0SDQzTXAzbkN4OUxBWVVDMWRLWjI2eFNDelZRZkZN?= =?utf-8?B?VlFXa2NEKzZxamRCNW9ocm9SSG5TZ0xGMllNVFNUNWVHNHZHak9vWEgxK0Js?= =?utf-8?B?TUhDQ3pEd0VmdE5HaUQrdU5tTkZxT2FOOHoxTkhLd0YyWFdUblRjUENZTFVU?= =?utf-8?B?cVlvVGZSSlA3VkpQemxBaEsyQVRqaGJXU0hSSXRJaTFuN0Z0L2hzY001S1du?= =?utf-8?B?ZWFIeWZ1K0tvUUVtN0dzUlZXcnZKbDlzRkoyQVMxdForYnVlaHVjQWJFYUI4?= =?utf-8?B?NUVyalhHWngwalRGbXlNWk9iQjVlUHVmMTJoUFJHbkk2OG1WSG1CTVlvWnR1?= =?utf-8?B?bnoxRnVFdE1RQ1RBR3ZML3BVY2o0WFpISktPSkQvc3pPU2Z1OENaaHNWYlFk?= =?utf-8?B?VmdiV2xBY0N4d0R1QVNEeUVqK0lSVGdkRkNyUTZQSFdyS2p2UWdSaGx0MGxt?= =?utf-8?B?dkRreDdBQVlTczJlbWVVa3A3cmdNWFVtRzIzWUxCZlZzbUFWMWtyQ01QZW1a?= =?utf-8?B?akxRa3NVWnphK0JtWXBERFM3YTQyNVJEUm93am5UZUNLeHcvcFdLdXRtTG4x?= =?utf-8?B?cDd2b3loeEtsNmpvQzE4VkFZM01IWUdoRGNyYmFWaW9pbnp4V1R5WlJzaENX?= =?utf-8?B?RGREZWhLQkN5aVgwaGQyak1HckxRNldxQVZaOVB0RzY4bXVvNWZoMW1rc0Fk?= =?utf-8?B?ck1aTnM4dUxuWjZhMmZlSm5vYlhSRUlnSmxOeWx1NklyeFg2SWZvMEVWdzQ1?= =?utf-8?B?bER2ZW1nRTRxWHd4YzVvZjRXS2VuTG9sMXpjaUt4RTdXbzlHU1gxb3JjVVRR?= =?utf-8?B?cjloVzJnNWZ6WHlEaWhWMXVJTzZuVjhTQWJSNWhUMkNxVldweFF3WGlQZWhZ?= =?utf-8?B?aXB2VXl2di94Z0UwUTFhZ2dTUUV4RnpJcjd2dWZ3ZEJGWnRtbks4cEhObWhG?= =?utf-8?B?WFYvUnA5UkhScjNMYnlLTHdoemlGbi9kZEp5c3Y3aDM4c3V4V2F0VGltZGNs?= =?utf-8?B?T0tudE9iQ1dmQmM4VzNNUTQzWitIV1NmZGw2ZVRJWG02ZkxNZnRYUzYwNDhq?= =?utf-8?B?bm5wNzRKR3NwYm1QWGtjNnFDQjVUbUpOM2xMcXo3QWlNSlRUVjdUMlQ4UjBj?= =?utf-8?B?RHdRL3V3YndhZTVIZ2hSOWEwbHlnVVBaRE05NktLU1Q0OExzOVBWM3ozVGNN?= =?utf-8?B?Um9pMitWQVVoeDNUTnRPYUw4ZUlNWmRKa0tOWmNpRjk0UTEzLzNva0l4RThM?= =?utf-8?B?UkROQmJmcFZwTW5oSTJ0ZkdDTEhPbDArSmhKVFF1T21FY2x5TVJ5T1hKa25T?= =?utf-8?B?S2t6ajN5dHhkbEh4UXhJN29WeE16cUtQK1NGYWdzb2lFaDRaV0pLMWx4MzVP?= =?utf-8?B?VFN6M2R0YU1mMTl0OUFpWmdWVzRERlpJREhPNVpJK1J1SkxjVWJ1TWNNRGl5?= =?utf-8?B?RjZ6a29kUXZLU2hMV09vRkN1NUpmdVIzMmRaMUdjWmEwcXFkVXBZVlNGQWNL?= =?utf-8?B?ZTVRcFkrcHhLTDRWdjFHVXUySnNobmdSclo5QnNHZEtQd0dGKzV2NldJeVdG?= =?utf-8?B?WWVYKzRvcXg5ZlR6MVQ0OXJSWExaQ3lwWlhZU0RWam1ZMlR5Mnk5QT09?= X-MS-Exchange-CrossTenant-Network-Message-Id: c22b07e5-01ef-463d-e476-08de6deadf50 X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB6020.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Feb 2026 06:07:47.3326 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: xHdzQKKOielQ1XuvJsa2ah1Zi35ujbXB7WJe2+u6fQR+HKAmoLlTTFI6l/ERifKOTSRWKrusuMiMy0Ps9aiqDA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SAVPR11MB9549 X-OriginatorOrg: intel.com Hi Prateek, On 2/16/2026 3:44 PM, K Prateek Nayak wrote: > 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? > Could you please elaborate a little more on this? If it covers the entire cpu_map shouldn't it stop going up to its parent domain? Do you mean, sd_llc_1 and its parent sd_llc_2 could cover the same cpu_map, and we should let tl_llc to assigned to sd_llc_2 (sd_llc_1 be degenerated? ) >> >> 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. > You are right, I did not realize that the tl->mask would be unreliable for detecting offline CPUs, and this case is brilliant for exposing the bug in current code, nice catch! > 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 :-) > Smart approach! Dynamically reallocating the llc_id should be feasible, as it releases the llc_id when the last CPU of that LLC is offlined. My only concern is data synchronization issues arising from the reuse of llc_id during load balancing - I’ll audit the logic to check for any race conditions. Alternatively, what if we introduce a tl->static_mask? It would be similar to tl->mask, but would not remove CPUs from static_mask when they are offlined. This way, we can always find and reuse the llc_id of CPUs in that LLC (even if all CPUs in the LLC have been offlined at some point, provided they were once online), and we would thus maintain a static llc_id. Anyway, let do some testings on your proposal as well as static_mask things, and I'll reply to this thread later. Thanks for the insights! thanks, Chenyu