From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) (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 196BF2DEA89 for ; Wed, 18 Feb 2026 15:22:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=198.175.65.9 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771428169; cv=fail; b=YxCHUgTtAB/FopKxVVYgvjLrwT0eyyZSOPBlF/tNMZulk+cdofyc5H1Q+IfPlLIkZ3VKJ/sk+YmgZnqzfPkH4x3Eph/71X5yS91dZv7tvOgh0fhoGczHITUlajR2/ehijsAU+gR3MAkSfGKZlG9T40MJOzjCuBh1eIPZsdM3yss= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771428169; c=relaxed/simple; bh=QHQekH7Oz4W/PnbXHxbTAT/rfp1mGcuHPM7ObCqTul0=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=Y9y4K6fKBeFokvG4m9yDe8yKZ59xtw8iNTEFKtao8/q0RFteOMfqR4JwOuyk2aLMLVm877G8lQn6GoZsHFecu2JAwjNFBjyPtA1mEIdc8s46Y0yBwi4dpyev1PvWQQznexB/JYGJ3M3vroGSDcEfXgN85OD8QyL0FWfeGwDiPqs= 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=I/pLTazH; arc=fail smtp.client-ip=198.175.65.9 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="I/pLTazH" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1771428168; x=1802964168; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=QHQekH7Oz4W/PnbXHxbTAT/rfp1mGcuHPM7ObCqTul0=; b=I/pLTazHID5wHLJq+wx2RpSDpklkgTwI7me5u/r0n92zci1gPuuKzTXD FGK0R72P7zMZZQ06N5EMjBfJltExoUeYV2hljq9riYG3fKlJHkfrFIXQS VyScezM4Tt48EolzKnH/QVN15nZDaWate+jEu4dMIM0tH+5JcDt/TpBfC pUO19Sm5zcitjD6o6jLZRLTN9wJiulPPPOQwk6nlMjqO2jjxRLccwPELt qQKl0fwL/X49E1r+3vWqzatlAx2JGswdf9l4rJxjFtObCSJw1hNXrYzUZ 7z9DRYEvQVK1nzFKPF9DePIdpXoxIGyjMdzG2Y+G55Irj95BImXSnaTOk Q==; X-CSE-ConnectionGUID: siHq/96YQN67TVaJQpxP+g== X-CSE-MsgGUID: HYvOKyE+TW28paYKETgvrw== X-IronPort-AV: E=McAfee;i="6800,10657,11705"; a="95127954" X-IronPort-AV: E=Sophos;i="6.21,298,1763452800"; d="scan'208";a="95127954" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Feb 2026 07:22:47 -0800 X-CSE-ConnectionGUID: n/ZcNEgLQyiiRdHiiQQnKw== X-CSE-MsgGUID: xN8PeOadTSqukTPtatdEHQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,298,1763452800"; d="scan'208";a="212995270" Received: from orsmsx902.amr.corp.intel.com ([10.22.229.24]) by fmviesa010.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Feb 2026 07:22:46 -0800 Received: from ORSMSX901.amr.corp.intel.com (10.22.229.23) by ORSMSX902.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.35; Wed, 18 Feb 2026 07:22:45 -0800 Received: from ORSEDG903.ED.cps.intel.com (10.7.248.13) by ORSMSX901.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.35 via Frontend Transport; Wed, 18 Feb 2026 07:22:45 -0800 Received: from BL2PR02CU003.outbound.protection.outlook.com (52.101.52.47) by edgegateway.intel.com (134.134.137.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.35; Wed, 18 Feb 2026 07:22:45 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Nh1Hg5C6XOecWQ/3y+bvMbcZAyplcCuczdltPZ29J2OpWp1OYxQoUAGJoglWbStWrnYoj9yT+m/OQanhCwDn21H0d6GSz2XA4xn+GrZONczD+FLILE+hTRTrYoBCxjS15dCMogeBj6N//IKAUZk34qNGppprt323vzS38q0BTud+BZGoWk235YRDDM6Qr2nc5RrqKWvBy3AAJ3BybRbVQgVx5SMYAzn31WRyiPuu1zdZCjqRmPxAsk15Kf79L3/kH5JbpQiimEcG5/Hu4dUQA5iCzEkT5oWDUS5IimE2qRFZa3Q3bz+dFKkatR8qarqPcw6p3e42FVmsuSUJk3gR+g== 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=aaLRU4NNg2Svvb/thM3K5DRHNJMelLJVcpe1/ItRzeM=; b=VcUNoPEYEAf+4QLoF7dgSQULc9dl9owFiCsYSaLARlSYlPYyBLfPw1sjOiFbGi3pIvhTtnhBs0Kb/69p7WKUyXNcUJI4PoxBavXE0X0K+OhTSiN1tdHNj8c7Q2jpylBcMDMMSXZqvXhx8vyXrfpT0Jf8pnJHBb+skxjzYVyBvT6yWuLm+eBTRbZN4bTnviYuYA1oBuZySGP/994Lo/50G6/e/oL+Qd4EqjfwNzCjLmln0jMZkZ7mhMRUSHAB+23dYXot20Ym2ifGNFCb+Ws4Y5G3ZLuLX2j2KpVONmlPwM3XwkzlvjOyKzGyMD/rmd8ZFUvT6cT+bN62E37zYzmTnw== 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 IA4PR11MB8989.namprd11.prod.outlook.com (2603:10b6:208:56c::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9611.10; Wed, 18 Feb 2026 15:22:41 +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.9632.010; Wed, 18 Feb 2026 15:22:41 +0000 Message-ID: Date: Wed, 18 Feb 2026 23:22:26 +0800 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 04/21] sched/cache: Make LLC id continuous To: K Prateek Nayak , Tim Chen 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 , , 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> <95923e36-4117-4209-97aa-a92b60f2bd49@intel.com> <6a73ac0d-1fc9-49a7-87a2-65951ab2c844@amd.com> <8df218ecf39015830856c7b1053a0f777cc1ea42.camel@linux.intel.com> <579c9039-cd66-41c3-8a72-e73d6f836ee8@amd.com> Content-Language: en-US From: "Chen, Yu C" In-Reply-To: <579c9039-cd66-41c3-8a72-e73d6f836ee8@amd.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TPYP295CA0044.TWNP295.PROD.OUTLOOK.COM (2603:1096:7d0:7::18) 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_|IA4PR11MB8989:EE_ X-MS-Office365-Filtering-Correlation-Id: 591d5906-31b6-4cc8-4e63-08de6f018ec4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|7416014; X-Microsoft-Antispam-Message-Info: =?utf-8?B?WTVLWDFiVmlnejc1aTNrZDR1Wlgyb3N6TnJjMlN3Q3ZlcWFrMlo3VU9wR2Zo?= =?utf-8?B?YTlnNGNzT2czaUdvWHBpSm5kOTZBT0lOdU1EcTlKbmU0SWl6dnRDREllSEt0?= =?utf-8?B?OTkrV1pjNkZ3amVoREN1NWxndFpaODBDcDhtdHJadzJLSGovYit5WEFpUkpw?= =?utf-8?B?MVVzL3NoK2xkM0YzNVBaQ0NMbUduQWQyT3puOWYrV3NpNzNIZ1hEMUZMYXRP?= =?utf-8?B?VHc2TG9NWW9KcGRSRzI3WHdiU21MdldZcGFXYVQ0QWl5MzYyazVCZXRYdWwx?= =?utf-8?B?ZnlnVmZXcGY0cVF6aU1mMDVYV3NMSjB6V3RLU1l1QXV2enRGRm4vMG1Scjh4?= =?utf-8?B?cXAvU2N1ajkyZ3dXa211eUJDVjBNaGpwc0ozb0g5emRhT01CZzNldmRUaFFv?= =?utf-8?B?VXJEeVJNSTlpaWF2OVhSclpYd01SeVZVZmZtaCtibWJZRE5MTDlqZWdhZ3Fv?= =?utf-8?B?ck5MZXY2cEJ1WnB1UUd1VVVUTTNoTXE2WUpnVXBsR0RMVzRjbW44blpLdEtM?= =?utf-8?B?UUNXVjE5TUFBcEtuNytYVmhBRDJuN3diRm1QNE95VWNkY1FkSjhRWU1vSURr?= =?utf-8?B?Uk9FWlZzV0tiZk4wNDJVUVBTTDBqOE1mWTgrY0hqbThlTmZBWUNCMy9oVVFW?= =?utf-8?B?WVZ5bzV1Z3lScGlYd09NQ29TbFBDSlNJT1Qxbk1qVTN3dTJCWlNJL2lSczk0?= =?utf-8?B?My8zcnYxUlNkVW9CNXFhdXFPdlhrOXVQWmNwMEcwaXl0Y2tzVnplUDVQaEh1?= =?utf-8?B?TDlXMFRnSEJqV3Q4dGV4cDJNcFRQWWdqazlER3hwVHFrdW5INFNldUMrRnQy?= =?utf-8?B?WkczK0szWGJhU2dQUDNWamRTS21xOXg0aERrdjBHazZtWWZmS1d4QWY1K2tp?= =?utf-8?B?bnpwc25GaWZ1NVlHSERmR3VWYXBRZlhZdnppNVZtZWRNQzVrR0R3SDg0UFZY?= =?utf-8?B?dlFITU0rbU42aE9MUnRJSE8rSnBlK05zdHBIMzFPZkRWUFdQZnNWV2Jha05V?= =?utf-8?B?cHRIY05lWEhQWWdJV3lSbkR0WTZESzMvTllFd0JQOFkwSU83NmROTktTa2F5?= =?utf-8?B?MmcxcGxjUjc1eFc1VWQ0bzVtRjFZY2x5ZCtnWGppc0xaUEZJNkV5eS9jQVVm?= =?utf-8?B?b3BHcVRxQWg0dXVFT2g5TU8ydytNdk1KTFR0dHAzTytrQTZMb0VDZFgvQW5w?= =?utf-8?B?S3g3dmN5U2xWQzlNTEhGVEVIUHRRNzNjQTNMazhTY3oyaXp6TWhncmJoUVlP?= =?utf-8?B?ZjhLYWtJa0NpOW8rN0ZHK3huak1YREg1V2VabDJyYS93emFZYjZPYW8yZkgr?= =?utf-8?B?VGkrMmgvY0tOWitHYVNBUVQ5RFJXRWdhUkN6R3M4RzlKYUpjKzhhaHQ2cnI4?= =?utf-8?B?VlJFeFBFWmNMN3FqZFFkUVpZNmJXQk5mR0RuTVdlejFGaVQ1SWFlbUU4Q1A2?= =?utf-8?B?dG1DQkVFak5POWxYTkhJZVFpOE8yY2ZuTkprU05kUHZSU21aTlIzcC8vL2RS?= =?utf-8?B?d1ptK0dYTEM4ZGdhVlZkRnFqblV1TzNUZ1dxR0JTOXV5cXp6K0VSdzhIcE44?= =?utf-8?B?ZDE5MUJEYnFYbHFlV0VKZTlqcytJVFNoLy9tUEdBUDk0UFBUL250MnpaVVpP?= =?utf-8?B?TnVPRkRTYXVuRGhNd2c5QjRPRmpMRzViaG92WDdOL1d0QWt4amVaM3ZRSWxG?= =?utf-8?B?ZU1nTTJSNHprTTNYNEZtbnEyYllzcU9EVlpiS0FOSUdjcnFnbWt6aTFOUEZ3?= =?utf-8?B?UVlYUFg3MTRJMnNOVXZvWjFxL09DNjhCL3JqS0kxdHR0Y2t4aHJqWnlVcUtm?= =?utf-8?B?b0RxZitSQWI1T3pxUktMdndJWHcyMHZlNWphY2pVcC9oQS9LTnlhRllzeFJO?= =?utf-8?B?TE00dU5uOWtPSzZIUzl3V0RlbEM0ZXV0WnJld2NwTHlGR01hTEtPbi90N2I1?= =?utf-8?B?WFlKazdYQnpadGZqQkNvZTZuVkhORzlmZVoxaTNucFNzeXozdkQzejdOSkZh?= =?utf-8?B?SGFIYXBJa2xXNUpSVEhhMzdHd1dUS2RHaHBGVVcxWWhHUVVHbTM2Ny9uaGxX?= =?utf-8?B?NHpGWTJucmhTMWQ2N244dHN5QUpvaGxMS3h0dWdjc1djaFVHN0F4aXo1NWZM?= =?utf-8?Q?JlRs=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)(376014)(1800799024)(366016)(7416014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eWoycVNwb2RVQXJmUHVOeHJZa0ZFTWF1aFlNTEFlRnVFOTJWdTVPOXBsamQ1?= =?utf-8?B?M3J3TEVIamwycm45M3Z4aTZnS2xUVTZ4R2hVL2l5ZW02QUs5T1dBR2oxMGdU?= =?utf-8?B?Vm9qM3BpdGtSNGZwNUpzb0JwQzNsazhMeXkxVlhPc3l5cjNWcnBETlJzUGlU?= =?utf-8?B?OEtLVjN1QlpQcVgzdklnVW93WmdoYnRWUzdZZ1NNWG5SL0R4U2xIcTFidW9x?= =?utf-8?B?cmRDVkxicXZabEZhdHh6NURDSFlYeHcxNjlEbTJQaGF6Z2w0NjRhOUp6R0Zr?= =?utf-8?B?amU4SGJkaHp6UUJrdDltS0hVeGQ1c08xN3BvWFZGaDNKbDIxajE1VXN0Zjhs?= =?utf-8?B?N29mU0FkTVptVmU2SWpITW4waEI3U25HeW1JZ3NJSVhkZURMeU92d3hrMExt?= =?utf-8?B?S0ozMHVtUTdjcURtNzlIOFREZlQzcXVNc2h4eFRaMExSdXRIZGt5ZEN4N3NL?= =?utf-8?B?TWlhK3grZExVWWgrVVg3NXk4K0hKdUQ1aFU5bmJibDhTelZhNi8zMnpuYkFN?= =?utf-8?B?eGx1d3A3ZWJHa2swTXNQTE9iZnFPVTR0d2JobG51SXgrNEJNbU80N29ncHlk?= =?utf-8?B?amE3eFFqakI3WXljcWl5S1ltOTVWYWFMYnRBVjR5KyswSkliQkc4OWZhWGVB?= =?utf-8?B?R3M4Ym0vZ1FiNkl0aU81YkdPR0lXUmM0VUkxMnk0cGgrRkxlTngzWnVlbExL?= =?utf-8?B?VjFlSWRZL1FTeE1QcUpOQnBZYTdkOFJRVlh2NzNEMDBTcmNCK1NIb1hPZjg2?= =?utf-8?B?R3J5a3lIb3FlYzd3aXNNaW5hVUY5S01HL3pkMm00U1YvSW5oTnZ2V292N0dY?= =?utf-8?B?RjJ0SDBMVUlSa2p5VWZGWTZ1a05waGRQYWpFTVFXVEJvQ1IySDdhQ05rTmVY?= =?utf-8?B?bGdRMTlrdHdoZDExVVdnU1hLZkpYRWRYRWRXYzI4d3ExUUo4OFVKK09GN1lK?= =?utf-8?B?OU9TSjQzT1FaRksvODByK29UdGtPRGFmdXBmTHBMSVJRUnlGQUdDUUZWNVdN?= =?utf-8?B?S0hsaTdkY1ZMSURaR2pDeFlpKzhIY2lOOG1jOEUyUGxSSmZnbnFnUTg1SWRK?= =?utf-8?B?L1BTZ0cycVZIbldXWDA1bHBKMkU0VG94VzhXcTBZTkNmS1g2dEVQTkpISjRR?= =?utf-8?B?NGY3TVpZNWFpVXFVTkl0Q0VyZCthdll6YnZ1dmVqa1Ircm5xSm11NHFCWjYv?= =?utf-8?B?Qkl6czlDYjlxbnA3bHlhWU5QUmZGOTJZbmt4ZnRDWUFOcUxVT1pZb0pWL2hs?= =?utf-8?B?ZFI4dHcwekRLNlRndnMyV1BnS1NVSkx4c0x4dVViWXJMcThhbVdvWWw1Q2JM?= =?utf-8?B?QnNjSUtpcDZIdWpqK3I0WVBaR2hkQ1l4NzhEdEY5RWk3ZnZ3NWtlMG9LclZj?= =?utf-8?B?RlA4VTJLQVNEMUhHOHFBMDBaRVVTRERWTWhmell2QTBmeDVwYTRGSVFsT0w1?= =?utf-8?B?aDlUN1pObnNUdGJEMUlvL29yRU10Y05mdXY3d3piY2p2VnVQWTZqMDdZUTdY?= =?utf-8?B?NndKTkhTcFgyQ29zTXZERW9JaEg4ZHo4RkFUQ2dyRXFkTm14UHg0SDJHRHpO?= =?utf-8?B?R0o2ZjBUcU12WEZLcTBZZlk5czlva2N3UXBEeTQzNjJBTlJZU0lmd3JWTkVD?= =?utf-8?B?Ujcwb09LQThzeFNsNXljbkdlZkRieDN2VjdodTBFdEJScEVCeDFCZUV0WTcw?= =?utf-8?B?VUszT3o3MUc3MHBObmVIWnBNc3FlaG1sWTJwankxSGJPVHlHQ3l3bXJNejI5?= =?utf-8?B?NEZpL3E2TWJsREpobWovN0dQTXFkdVd3K2ZjalRQZFQyNjBLQkp3NWQwOXRk?= =?utf-8?B?SGExZnNYVU1Lc3B3aHNFdHc2SFc1WGNWQ1dqeUc1eUNVUjZrZ21DTWQ4MDJu?= =?utf-8?B?dDNZcERTbEpUb2NRWnpnQUI0MGlaeHIzT2l4Zk9lMlNDWEpkOFdrZVlaTEF0?= =?utf-8?B?SFZpL3Z6Ukl4Um9GRTZBc09oMEhGVjBYc3BiaWpxMStENVlkM3Y3SWdmWUZH?= =?utf-8?B?WjVGbjk0RGlnbDltZ0UvRHBOcENJTzZ0Y3h5dW8xalBZaUQ3aDlWaG16MHpq?= =?utf-8?B?V2s5SC94SkFqMXdpNGFHeTBRbTNIUkNqb3l3bFFXRTR6Vm1QTU95Njh0UllJ?= =?utf-8?B?bnNzQW9vTldQTG1penB2dEZzQS85Q2ZXSXJZYlhyb2doN3pLVEowdFp2cXc0?= =?utf-8?B?Ym8vK2NSdVZIRjNySWk2dWJHUUJ3eUhBQVFXc0ZDU3FERXBmdnhuNXY1akZs?= =?utf-8?B?TTBUWkpHVE5nemZ6cXVMNEM0dHVKTTdUd2hCcS9ma3ZMeFYzdlc5d1NHNlU3?= =?utf-8?B?bnU1R1lBdnRDSk9pYUlNSHJDK21oTHB4cFpKU0FLelpZMlV4VEl2UT09?= X-MS-Exchange-CrossTenant-Network-Message-Id: 591d5906-31b6-4cc8-4e63-08de6f018ec4 X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB6020.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Feb 2026 15:22:41.7169 (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: TQTc9tglrCPqYCj8jfay4zDdlLLNiLxskGWYScnSu7LJKC1zlaXLVgp8ZL6rdJJ8yYK40SihpMDkXfk2XUB0sw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA4PR11MB8989 X-OriginatorOrg: intel.com On 2/18/2026 11:28 AM, K Prateek Nayak wrote: > Hello Tim, > > On 2/18/2026 4:42 AM, Tim Chen wrote: >> On Tue, 2026-02-17 at 13:39 +0530, K Prateek Nayak wrote: >>> Hello Chenyu, >>> >>> >> >> [...snip...] >> >> >>>>>>    */ >>>>>>   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? ) >>> >>> I'm not sure if this is technically possible but assume following >>> topology: >>> >>> [ LLC: 8-15 ] >>> [ SMT: 8,9 ][ SMT: 10,11 ] ... [ SMT: 14,15 ] >>> >>> and the following series of events: >>> >>> o All CPUs in LLC are offline to begin with (maxcpus = 1 like scenario). >>> >>> o CPUs 10-15 are onlined first. >>> >>> o CPU8 is put in a separate root partition and brought online. >>> (XXX: I'm not 100% sure if this is possible in this order) >>> >>> o build_sched_domains() will bail out at SMT domain since the cpumap >>> is covered by tl->mask() and tl_llc = tl_smt. >>> >>> o llc_id calculation uses the tl_smt->mask() which will not contain >>> CPUs 10-15 and CPU8 will get a unique LLC id even though there are >>> other online CPUs in the LLC with a different llc_id (!!!) >>> >>> >>> Instead, if we traversed to tl_mc, we would have seen all the online >>> CPUs in the MC and reused the llc_id from them. Might not be an issue on >>> its own but if this root partition is removed later, CPU8 will continue >>> to have the unique llc_id even after merging into the same MC domain. >> >> There is really no reason to reuse the llc_id as far as cache aware scheduling >> goes in its v3 revision (see my reply to Madadi on this patch). > > Even I don't mind having some holes in the llc_id space when CPUs are > offlined but my major concern would be seeing an inconsistent state > where CPUs in same MC domains end up with different llc_id when after > a bunch of hotplug activity. > >> >> I am thinking that if we just simply rebuild LLC id across sched domain >> rebuilds, that is probably the cleanest solution. Tim, do you mean reset all CPUs' LLC id to -1 whenever there is hotplug event in partition_sched_domains_locked(), and rebuild them from scratch in build_sched_domains(), so we already refresh the LLC id for every CPU(I discussed with Vineeth here: https://lore.kernel.org/all/54e60704-b0f3-44df-9b83-070806b5a00c@intel.com/) >> There could be some races >> in cpus_share_cache() as llc_id gets reassigned for some CPUs when they >> come online/offline. But we also having similar races in current mainline code. >> Worst it can do is some temporary sub-optimal scheduling task placement. >> >> Thoughts? > > If you are suggesting populating the sd_llc_id for all the CPUs on > topology rebuild, I'm not entirely against the idea. > > On a separate note, if we add a dependency on SCHED_MC for SCHED_CACHE, > we can simply look at cpu_coregroup_mask() and either allocate a new > llc_id / borrow llc id in sched_cpu_activate() when CPU is onlined or > reassign them in sched_cpu_deactivate() if an entire LLC is offlined. > Prateek, may I know if you are thinking of updating every CPU's LLC id during its hotplug and not update all percpu LLC id in build_sched_domains()? thanks, Chenyu