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 7AA2D33A71E for ; Wed, 24 Dec 2025 09:46:40 +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=1766569603; cv=fail; b=XoX2KfxIAOGYI9oYB21dyrhl5FcsSZg2hITWUHJilPIUvKZIkHh7G+p+kzca62NM1foLafdkxehYqL2P30NhvJD8R5cDnjdJn/oW8pgRdvwD69Ppb+jC/6a7S6CT4kCkScI+3fToRr4MIbgL0TBvADiidHQNeQoQOvSUEx+oGl0= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766569603; c=relaxed/simple; bh=znoqYkD/U+EUauBbHAiinFg4D9W5d7R6leo5JvHJpD4=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=q5/6Tjpe1QepaExwvcC/Qh0lcR/deaiCSLjhcPsNtpwM0G3Gpds/YNMnm4VM9LrmFyxcG4YB+zDZlQV3l4DznPHJaRburCcBjbWVpWz+RcmekPFYKyr/9wRHPNrkyzFTh1LBJvFGuXI6qgqmRFk/zuqNwLizgRJVMatjO9aQJaM= 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=bnn6pgRD; 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="bnn6pgRD" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1766569601; x=1798105601; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=znoqYkD/U+EUauBbHAiinFg4D9W5d7R6leo5JvHJpD4=; b=bnn6pgRDQLnddqyew9pzO3fLffyO5+8DpG0vJnnIWx3gPCEl88F/gSPG QFLrIKC+JAIxytWD3177cvOOFLkZs1U/iKCB7aQY0ieHn6oUHIfWWAuCU DOUTLA1Bu9w+h8pYRLvRCqoVrC8VYhuIDNy6C4gqeyWC+JJSZhY+xMuNK ykJXekYxrAJZ92c1eAYzwc6fyibXNmuEVuhBoQKBI6lSVuBO2deqP2ZvL WP7kScLCB1vDX1PEf47avth/F9rrV1X0MWvHcUG6L/h0lBNuiOZdkwXDg teXhczwbLvJB5Tio0lRiF1CP17PXciA1T3/M59RoiFeZEsLDIc5TXSiOF Q==; X-CSE-ConnectionGUID: 1nZuj1MJQamR5Xe+FuSqdg== X-CSE-MsgGUID: tmPqX2VaRVuOUxzd2tQeRw== X-IronPort-AV: E=McAfee;i="6800,10657,11651"; a="91065722" X-IronPort-AV: E=Sophos;i="6.21,173,1763452800"; d="scan'208";a="91065722" Received: from fmviesa005.fm.intel.com ([10.60.135.145]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Dec 2025 01:46:31 -0800 X-CSE-ConnectionGUID: GORX3UhlTI2zArEtJ1xpag== X-CSE-MsgGUID: phKHuOJQT+ek1yHmUPVluw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,173,1763452800"; d="scan'208";a="204491338" Received: from fmsmsx902.amr.corp.intel.com ([10.18.126.91]) by fmviesa005.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Dec 2025 01:46:30 -0800 Received: from FMSMSX902.amr.corp.intel.com (10.18.126.91) 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.29; Wed, 24 Dec 2025 01:46:29 -0800 Received: from fmsedg902.ED.cps.intel.com (10.1.192.144) 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.29 via Frontend Transport; Wed, 24 Dec 2025 01:46:29 -0800 Received: from SJ2PR03CU001.outbound.protection.outlook.com (52.101.43.24) 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.29; Wed, 24 Dec 2025 01:46:29 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=LMs0+HqVmnlPQ85vjxxLom7kIy3eXecv4OQ9SYRwWfjVb/NoDO0FUHiCzUItiI2ej10AHwRRxcIOYvzUZxJnCwb+0EGZwNMikqlUeaSnpHm0px/XHsxakyCo+mUkf3lqavRhCt/yOF/VUqaGKd6XWczlTz5tr1XGwDpqSVXkTjIGQfps6ehWP7frbAPXfjChGL0sumCWXJ30Texj+qvRtaUNSTI8X3c+TwJIbqp90xP14v+3232JsPvvWWMFGZTwDF+YtSuAlq8v0TEveLX/6Xy05uYj0/IqUDLgjemnLL4DD3gZNXCW0yvDKin8Un62TtK5JHEow2YduPHf2F3cEw== 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=gLzwjn7nifqHPnHBovC9PHw6KOWtP4imYpC6YZx9xak=; b=xJAKSCsCpl0rAxvU1e8dvNgpmeOPCJ4Ev9s/zRlTY/6BrZjPgRmDOrsAUgxCYyiq45npy9hJlUUEj0SGdTExVHJXO8ebyZa9LDjLMzRsGSaoZOIAvEHbDRSsv7T+Fu4vtpuPZhMdMfYhfIe/GYXy/Mk3//tYf/gKfJS2AxlRjMEx4XiqYvbiXnzT2EMn73WXqi2g+BwZnDJZ/VAMBXmE79q+eOiHDRqXMe7Ph/KucZZPjCuLp8jns1KZZp65RtqC1I+9eTneY/+W++39/t2KJGawTxGfocmFxBS0ei635tvo00tbQZW4W3Aw7UnXdldjnDcvCsEoRTGO0mhX88OCyQ== 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 PH7PR11MB6005.namprd11.prod.outlook.com (2603:10b6:510:1e0::19) by SN7PR11MB7975.namprd11.prod.outlook.com (2603:10b6:806:2eb::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9456.11; Wed, 24 Dec 2025 09:46:28 +0000 Received: from PH7PR11MB6005.namprd11.prod.outlook.com ([fe80::4f64:b0b5:4ed2:39ae]) by PH7PR11MB6005.namprd11.prod.outlook.com ([fe80::4f64:b0b5:4ed2:39ae%2]) with mapi id 15.20.9456.008; Wed, 24 Dec 2025 09:46:27 +0000 Message-ID: Date: Wed, 24 Dec 2025 17:46:12 +0800 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 04/23] 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 , Ingo Molnar , Adam Li , Aaron Lu , Tim Chen , , Vincent Guittot , Peter Zijlstra , "Gautham R . Shenoy" , Tim Chen References: <2f9165fe-55f2-4919-be01-e9d2cdd1f960@amd.com> <70ac9110-d899-4a74-bd3f-54a486a7e45d@amd.com> Content-Language: en-US From: "Chen, Yu C" In-Reply-To: <70ac9110-d899-4a74-bd3f-54a486a7e45d@amd.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: KU0P306CA0058.MYSP306.PROD.OUTLOOK.COM (2603:1096:d10:28::14) To PH7PR11MB6005.namprd11.prod.outlook.com (2603:10b6:510:1e0::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: PH7PR11MB6005:EE_|SN7PR11MB7975:EE_ X-MS-Office365-Filtering-Correlation-Id: f55cdbd8-528f-4625-392f-08de42d14f31 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|7416014|376014|1800799024; X-Microsoft-Antispam-Message-Info: =?utf-8?B?cGhtOVpYYVJrTkUvcHpZazh2d3loc1VZdHJ2Rm9ndTU1ZVFRaE91bFFmRStV?= =?utf-8?B?OHorSEo5eThoWVYwR3JxQzI0dnUwL0hFazdoQnFkcitDY2dnUlZCbVpBYnJx?= =?utf-8?B?TjV2RXF3OWhqZkVHNmU3VWg2TVJPaFdBSFZBK3ViWmVBaVlTVFNtcjJubnpU?= =?utf-8?B?dnhtK0VheEhxOE9zWVFsQmNTNFpFRHhqcmJ0UzA0NUx4T1NURXFIWjZnWDlZ?= =?utf-8?B?MEFBSmFGaHIrMGxLNk8xQkNqUnZpUVF3UUlqcDR6K21hd2I4RDZNa3JZRDRM?= =?utf-8?B?VFA1OUMrVzExMFowaFI4a3FheE9OZkZ1MlNWVVpod2lKMFNKb2ZwR0wzWWpX?= =?utf-8?B?MHoxZVRpQzdXL2RzZ0R3R1dtMU9UNVlLeVF3WjRLRXdMekkxMWxXOU9mU3lt?= =?utf-8?B?cE5sS2VQNVEwaHJJOFB0TC9oYStDUDF1akhiRE9PQzNYQUNtYmwrRW9xUWNV?= =?utf-8?B?d1ViOXhVc1ZxKzAyQzhOV0dYZDVEK2F2eTB3KytlaDlsY202YXJ5cG5hV004?= =?utf-8?B?RmRFL1FyZGJGMWR1aW9WT01icVlhTklobEl5ZGg0ckVIbll2Q0diQ3pjQXJL?= =?utf-8?B?a3VodUNFb2d2UENkNjdMNVdhTkdqbWJDZzFQY1g2U1F4YUtseXRjNEFEWUZJ?= =?utf-8?B?aXhWdVRMd2lwVXg3T044OUl1THFQMHJtRDhXbFE4SW9uWklpb3BuMlhrbGZp?= =?utf-8?B?aDIwbTd6OWE3Qi9jekNmMmV4bmI1VGlpTWRuS2ZhOUdpYVRTRDRhd2ZlUno5?= =?utf-8?B?MFU3K2tmeXQ0SmNTNlJiQzA5VFhkMEZhc212eHRIaVdqeW9oaGRBRlBmR3JD?= =?utf-8?B?S1RrUGM2Y1JIRUxuTUtRdlljUWR6aXdBQ0dyVjJNQ1VjdHpEa0szNjAxZ2dJ?= =?utf-8?B?S0JWTmgzK3BWMEdMVGhJM1g0MVpUdGlpcXh4TG5OUnVPV0twUk5lL2p2NWNz?= =?utf-8?B?YUIyUlRoK3JFaWR3SHZOZjNST2ZFOEtQRkduQU45bnR1VDVlTGZDc0J2cnI0?= =?utf-8?B?OVhQUWk0R3JvNXltUFhwQ251VTg2RldkdDdSeTBxQ0pXODcxdmVUMEE5TjhD?= =?utf-8?B?UW5JcFJxK1ptNDArVUt1S2JQTVU1ZXJIdzBva056aSs1bUhwMVU4cTNrYm1i?= =?utf-8?B?ZXAxeE8vWHhQcnRPZDMxRmg0cDZZSmY4U3J4T0NvSU5xbnZyb09pbmZEL0Qx?= =?utf-8?B?SjgwblduSkpMb3FvZExWS3ljOE0zWVg0cng5UCtDc0UvTThNNzhSU1pYenRp?= =?utf-8?B?Y3UvNUVDSTFlVWt6UGZPTTFhSVl0aytSZHZJTkVqV0tWNTEyU29KckdRSElG?= =?utf-8?B?Rk0yd2ZuYXFqV0J1NUFLSC84SnNlV3BDS0NvQ2FDK2VGYit1YWVRVzdKaHdJ?= =?utf-8?B?dk1xNkNYM1kxZDJrVS9meEprcFdEWkZEWG9rUXNzeEY4SmhLQ3UyYXFDRzFw?= =?utf-8?B?dVhRTVNwQVJEdGNIS0srWW5kcWJpOEFNaE1jVG85M21GMFE3UmM5Yk1IRzVa?= =?utf-8?B?c0JKMTNMMExpZTZwb2dnbWxmNmI0aFhYUWQxd3RvQVhIaXhaS2FKUXk5VmdR?= =?utf-8?B?RHRhSUJ3bXN5eXpmUHl0ZzFhRCtyTXhoMWxtOVY3cmZqMFZhcGFmZWlmNERB?= =?utf-8?B?bnhuRzJiT1h6aFVOaUx1MEtVLzFGZml4Z2lhMkl5TE5JTEZ2MDhVMmNjaWN3?= =?utf-8?B?cDhIYkkzdW15c3Y2bkNFWlp6elF5YzBUWnFTUEdyeGtZMzlWOXdXb3FvVUtB?= =?utf-8?B?cXVtSzhuM04rd3Z2bnIwOUxxbkxjQ3RJOHhNbk85QmNOWmp0a1F1SlZiQzdL?= =?utf-8?B?Z045bDhHcTJnVXpzcGFUU3o4VlpwYlZGcmhQcDRnK0NoRHd0bEhqVFZlM1Nn?= =?utf-8?B?UmQyYmprQXp1QTQzaU1meXJPL2tzN1FVUHNldEY3VmFuZE4xY3RXT2VnajVJ?= =?utf-8?Q?EySS2tq9GRBQZ7fkKq5GjBEIYH8tOIxC?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR11MB6005.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(7416014)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UGJndC8waTNCakhTeWNiTXY1NVA5a1NoeGV3R3NXb0NpSm5XVVNnUTRKZmRo?= =?utf-8?B?aVM3bTNQQXEyRUdVRXF1dmdUcXlnUEV0bHZHNzFYcklHeE9qYk9zTEtIUURT?= =?utf-8?B?VzlqbEE5bXQ2emhON1ExcHN1NnhGaCtLQzl3SHU3UDlxZVRPV2Y0TEJuYjR4?= =?utf-8?B?amlFQlhWSEVlUmZsdURRTERuNEE3c010RjA3N01yTVgyTEQrbmNpZ1hvUUxK?= =?utf-8?B?WnZpZ1BtaU5LV3FsWnpnSVJVYmszSGRRaC9EbGZRVTFHRWVQWmNTaTlLV0l4?= =?utf-8?B?Y3hRb2M2ZU43ZjVkUnNkclV4SzR2YlF5YjJSc3hJRThONVAvRHBxTmtrcGhL?= =?utf-8?B?WmxqNmFLaWd1d0R4ZVg1WnpmOEVoQTNZOERsRlpvM3BhMHBqTlJzbUVVQytw?= =?utf-8?B?YktNOG9mTzNlSUFSVGVYREpqSGw0Z3BmVTZKTVJyRFN4WWs2VnFWcmhhZ0dj?= =?utf-8?B?SmtPWGgwSXJIZks0ZWtzenArZi9QdWZubUNpNndhbXo2Q3ljY0xINzEyakpj?= =?utf-8?B?WHNHcnNCV1lpT1pPQnc4OFYrUDhYYi81ZUplM1NkY3FFZzdkb2ozREhiTHdO?= =?utf-8?B?REFnWFJxbVFxV2JhakRpODFHdTNCSWoyQnA0TmkrUm94OHI4T2tFenIwdzhD?= =?utf-8?B?TTYxMm5lSnhSdXR2bTY0ZmpQUVRLREtmYWtOaHdxS3FMWTRFVTFrS2g0UXlx?= =?utf-8?B?cGRjOWZlRlh6VHlpNEpvQXdxb3c5QjNWSjdUSXNHMWdvaGlVaWVzT1pWaU1l?= =?utf-8?B?R292aER6V1JSbm5xRStsZzhOejd6bHVYamlmbmRmbE82L2c4Qko3enYvTDJl?= =?utf-8?B?bDNKSjVUb2g0Y2dyTTVNeTBiMEJIcFN4aDU0YnM2TW9pV0hlckh5TlMzNEQz?= =?utf-8?B?VzY2SE5hQXhwUkZjemdITERNK29CRGNUNzBBTEpSVHBUK0hVV0dhWWRRZWRY?= =?utf-8?B?d0hUcTFaL3hpMzR4YnRlTDdKdkxCSjB2MG9DYmF4d2FMV1d1aFJGZTUyZDBm?= =?utf-8?B?YnRzQlBJMk5RK1ZPNTQzd1lnMlQ1MTZxVGcrcnhzd1VCOW5xc1NONEw2TXUy?= =?utf-8?B?NTZ5SVViWXlmUTFhNFZ1dVBLVms0T3gvNVE1cXBsOTdDaEFvYStUbmgxZDhr?= =?utf-8?B?ckdRSWVKaWMzVUtvSENMa3gwZXgzQ2M5Z1ErU1p2NFFQVENyeXo0cU5jNW9E?= =?utf-8?B?L0NFMkwzT3psMzhPZjhaRkhQb2czdURiM2pOQ2grSTRTNGxMR0szbEhXZ0xF?= =?utf-8?B?ZjVOaVhrQmlXMVljQkVLT1UxWlB6bm0vWGEyNFVVTVRVWTBOd2RoRHFRaXhq?= =?utf-8?B?bFk2Wm0xZm9OZHVkVnc5S3JkNzdvVytwZUgzNnRPdXJOdFRlTWloM05BbnFK?= =?utf-8?B?U1pxMHhURWEwZXVIM0xuTXZ4TzZwOTJlRmVjYThPcy9PbmZmaFgzdUlwZk1q?= =?utf-8?B?d0hXTDUra0RFWVlVVmdmWUdHSTdvM1pta0pMMW1pSFQwYThzWm81c2dzL24z?= =?utf-8?B?QTlzKzZxWWVIcTJsZ0d1MlhJY1ROd0lVdVVvRXZ2ajlEaFAweDFHSDZTOXVX?= =?utf-8?B?MUlpS2UyU2x4NEE1akI3enVWSDlLSVN2Q08wUlJzOG4rRjJIbXNWOWtCcFFu?= =?utf-8?B?YXh6MDZKM0pUS0RQbW1BeUY2V0MxdUVsY1hIdW5MN09pSFJHMDNZSC9mTkRw?= =?utf-8?B?TG5wZkUwaXZ5UHJ4aTBieTkyS25OQzlLcStJeHBoeTVydU90anNNU1VSZ2dN?= =?utf-8?B?eWFDbEZBRDZNK3F5akx6N2I0NGlzTTJZMWZmZW9xdzdXOGhvUGt5YUFoOXJD?= =?utf-8?B?aE93a2pWQ2ZTUjVuUXoxRmpKK2JnUW9OL3Q1cDBQa1JvU3pxeS9jMjhhNHJz?= =?utf-8?B?K0ZGblJYU3U0VG45WDJGSUlBMTVJMndIMmc1N1NqT1FPR09ra20vZ0ZDSkJN?= =?utf-8?B?cnJXNVcxS1VSczU1dWZkUFRjTUlTSEJlb253Nm1DQlJka0RQWTRJM0hzd21y?= =?utf-8?B?L2g0TVIyMExNWmxiSlkrSFFoNlhZcHhCcExvOUIremQwZU1mNzQvWVdYMHNE?= =?utf-8?B?UGJNcE52MVN0VEpyTzV6Z2FEOVB3bTZjTmdIZHhxK1Y4RGF5ZFBsRitPejZm?= =?utf-8?B?VisyQUlXY3B0aExSYlZYSTBFWmFnUGlKTitqeFFOUTFSaU5BbXhPVzRnM1hk?= =?utf-8?B?NGZkSEVNbHdGdExxMk9tSWpycHQ4WVFzQ0p5TjdUcU5RNE9GdUEzZXg2dUov?= =?utf-8?B?TTU2bVNtTmRNSCt0b1NjWnNqTXN1RVpTQW9sQ2NZbEFSL1AxaHJmTGpXQzQy?= =?utf-8?B?LzQ2Mys5bWYyQk9Lek9hK0N0Qm1TQXZnQkNLQlBRQmkvTlJTUlBRQT09?= X-MS-Exchange-CrossTenant-Network-Message-Id: f55cdbd8-528f-4625-392f-08de42d14f31 X-MS-Exchange-CrossTenant-AuthSource: PH7PR11MB6005.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Dec 2025 09:46:27.8560 (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: veCxMG4n90u3l/clX8bt38hiL3qVXeqrESfm+CvZHacnAPo00w4KqRLIvuSl2zAUN0JqZtBU/AjnkD33L4t56A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR11MB7975 X-OriginatorOrg: intel.com On 12/24/2025 4:19 PM, K Prateek Nayak wrote: > Hello Chenyu, > > On 12/24/2025 12:38 PM, Chen, Yu C wrote: >> Hello Prateek, >> >> On 12/23/2025 1:31 PM, K Prateek Nayak wrote: >>> Hello Tim, Chenyu, >>> >>> On 12/4/2025 4:37 AM, Tim Chen wrote: [snip] >> I'm OK with replacing the domain based cpumask by the topology_level >> mask, just wondering whether re-using the llc_id would increase >> the risk of race condition - it is possible that, a CPU has different >> llc_ids before/after online/offline. Can we assign/reserve a "static" >> llc_id for each CPU, whether it is online or offline? In this way, >> we don't need to worry about the data synchronization when using >> llc_id(). For example, I can think of adjusting the data in >> percpu nr_pref_llc[max_llcs] on every CPU whenever a CPU gets >> offline/online. > > So I was thinking of of expanding the rq->nr_pref_llc[] if the > max_llc increases but leave it as is if the number of LLCs > decreases. That way we don't have to worry about the > dereferencing past the array boundary. > Sure, we can do in this way. > We can also have a wrapper like: > > struct nr_llc_stats { > int nr_llcs; > struct rcu_head rcu; > int *nr_pref_llc; > } > > And re-allocate and attach it in rq_attach_root() during sd > rebuild. That way, RCU read-side can always grab a reference to > it, enqueue / dequeue don't need to care since it cannot change > under rq_lock, and partition can use call_rcu() to free the old > ones up. > OK, doing it in this direction(and Peter also suggested something like this in the domain) >> >>>           cpuset_update_active_cpus(); >>>       } else { [snip] >>> AFAICT, "sd_llc_id" isn't compared across different partitions so having >>> the CPUs that are actually associated with same physical LLC but across >>> different partitions sharing the same "sd_llc_id" shouldn't be a problem. >>> >>> Thoughts? >>> >> >> This means cpus_share_resources(int this_cpu, int that_cpu) Actually I was about to say cpus_share_cache(). >>  should be invoked when this_cpu and that_cpu belong to the same partition. >> In this way, we do not alter the context of cpus_share_resources(). We can >> conduct an audit of the places where cpus_share_resources() is used. > > Only case I can think of is a task wakes up after partitioning > and it's wake cpu from a different partition is mistaken to > share the LLC as the current CPU - but the task cannot actually > run on that old CPU and it'll have to take the > select_fallback_rq() path if prev_cpu was selected during > wake_affine(). > OK, make sense. Actually, prev_cpu might not be chosen by select_task_rq_fair()-> select_idle_sibling(), because fast path select_idle_sibling() is expected to be triggered when prev_cpu and the current cpu are in the same domain in select_task_rq_fair(): cpumask_test_cpu(prev_cpu, sched_domain_span(tmp)) sd = NULL; //wake affine curr cpu and prev_cpu are in different partitions, they are not in the same domains. > I don't think it will be such a common occurence to cause an > issue and even without that wake_affine() could still the > prev_cpu if current CPU is busy or via wake_affine_weight(). > I realized that sched_cache has added cpus_share_cache() in several places, most of which should be related to load balancing, which should not be a problem if llc_id is shared among partitions. I'll double check. thanks, Chenyu