From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.18]) (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 3DDDD23958D for ; Wed, 17 Dec 2025 05:25:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=192.198.163.18 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765949148; cv=fail; b=Rkvj/oLn4jB1AK8UyUbJQHzzxTY2LqoezyLZzMBE3QOJEA1u8GZcxJSyBVOOWY/ngzBZevfBCOxG+SaX1XNcEMFiqZ/GWWbxWclSYVLskVUTK2dIt2gl6pqBd3kUduZ1UhnF8xzAfAC4I3MKHCEaLStFsMBuuSmONEUW5fTDv/M= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765949148; c=relaxed/simple; bh=z9Bi8/lrF5VTTgtejLFcAwD3NdiurOt4Yl+zWY3t120=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=H53ZfK2vIO2mOORTSOpMdZCl69iCjP5Evg+DJaVAmAdgBF/pEJ9/F37hKWZiXrw1s+LkaLV+42sJnaGz1jFX6ZiRE9REgZfTGgd/H3MTLc0OjLfyy0lxRmHzxiV2wiSkfOrfUPKpwcWE1Y1AMS7c2sg4auq4MgvkorVAO3Xdk2w= 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=Trrfh0WZ; arc=fail smtp.client-ip=192.198.163.18 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="Trrfh0WZ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1765949146; x=1797485146; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=z9Bi8/lrF5VTTgtejLFcAwD3NdiurOt4Yl+zWY3t120=; b=Trrfh0WZmBVQFGLYxzZNF/a1vA1f1z47MEJOSSr1wcfqYqsCL+WwuL5x 3a1S3AjNEqQZtBHR/LhmO1k+412bcjOpwJtSGc1q+kxEqsOgsQHo4D0BD 8ur3BLyyIgx/nhn/2UepuNw9lxujBsofX3TDDkxGnlD9Ry/uLXVS5td6W lpS0c9UN/B3LctQmfD638/c9sU0PbuCFsZzo0BzlSRTrNZ8a9L3Yr1I33 Vit0L04Mu4KuTs9mkk6TdmnPDo4Sx1G7QyW38rJ2zqvl6pV0xfBxmLOtw gZhs8bANE1+kOEw7tiRgaNWF6yA3FODxdmwW8lyuDOJ+8gEor7EiuIQPi A==; X-CSE-ConnectionGUID: bFEb6cfMQcaHUka6gshWXw== X-CSE-MsgGUID: Kl4/gUPsTXqxkZ9Ch8RixA== X-IronPort-AV: E=McAfee;i="6800,10657,11644"; a="67072400" X-IronPort-AV: E=Sophos;i="6.21,155,1763452800"; d="scan'208";a="67072400" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Dec 2025 21:25:45 -0800 X-CSE-ConnectionGUID: WSKrFnwWRRaHywrsA44x9Q== X-CSE-MsgGUID: e6LFrxZlRnW02hBSrlTyHw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,155,1763452800"; d="scan'208";a="228905043" Received: from fmsmsx902.amr.corp.intel.com ([10.18.126.91]) by orviesa002.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Dec 2025 21:25:45 -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.29; Tue, 16 Dec 2025 21:25:44 -0800 Received: from fmsedg901.ED.cps.intel.com (10.1.192.143) 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.29 via Frontend Transport; Tue, 16 Dec 2025 21:25:44 -0800 Received: from DM1PR04CU001.outbound.protection.outlook.com (52.101.61.34) by edgegateway.intel.com (192.55.55.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.29; Tue, 16 Dec 2025 21:25:44 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=i5C9tXzA6ZVo9Tem7kED+O4Lk1J34MVBxFYSp6aC4F8pMZReNeYKtkF1HY/YHnpf3CoKZmgsnrHOda53DgZHDe8yGuTCZXhZXPZ0lWftOLEK4SRNygAdXboSFKt0f5rr4zcy20tV6oaKViO8e0T8XQsW8owIbWJHahg0RTeRcL+yjJ+KhRpS1PAR2bbPQuVfOfRWqhjbJT6w23hDLJrtsggjsBB0V6220wE/BuvAVw/kL40JlXj1CpKEFDZMmT7M6XIYJLqA5IovZ7clvlmlkvbRJ/trzEkra+JrnQFLdeXRErFvNw3Fkpu0W3esni8bBdh/qWoT8ZbHT4ShcAA6qg== 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=L1BhiFGhsb89BtHK94QLHAIJ8l0r4g+mwk1XbOEASDg=; b=RIKKdPA8yDAmPEWcqWt8eeMsBAZzVqld2XqNl8e4Zd7QDBi3agMCpREErMXgA+dlVS5MHICIuF2hp09TNcriaaS0U7lHPeNg5z4p8K3Gh/PxGllfI2jM5aKU3Yah0nFgy1W5kOotMCXUA8sGz0ZIygVI1IqyFtY8cBGUBgS/uyntCaMC1KFBr/0pEmT/lcj0Q/BZtl3StBTeMI+hDCOiyf4Ryohn8tTZg/9RFvl6Seatwc0KVWRQs9QnGhIw8A+XDrpGYNWEW3xKWnxLu/C4sijxo6QMPZlHw4LAcGsLNOfTs3yRRnJW3aZMm+AK761Um6nN4ZDI9CD5WMJrSsULAg== 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 LV2PR11MB5998.namprd11.prod.outlook.com (2603:10b6:408:17e::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9434.6; Wed, 17 Dec 2025 05:25:40 +0000 Received: from DM4PR11MB6020.namprd11.prod.outlook.com ([fe80::4af6:d44e:b6b0:fdce]) by DM4PR11MB6020.namprd11.prod.outlook.com ([fe80::4af6:d44e:b6b0:fdce%4]) with mapi id 15.20.9412.011; Wed, 17 Dec 2025 05:25:40 +0000 Message-ID: Date: Wed, 17 Dec 2025 13:25:24 +0800 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 04/23] sched/cache: Make LLC id continuous To: Tim Chen , Peter Zijlstra CC: Ingo Molnar , K Prateek Nayak , "Gautham R . Shenoy" , Vincent Guittot , 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 , References: <20251209115846.GL3707891@noisy.programming.kicks-ass.net> <3bb9bf31222af552ee4b0db30bb1624bd84d3cba.camel@linux.intel.com> <09a6d7832003733acbdf6bcc5f6f32b55a0caba4.camel@linux.intel.com> Content-Language: en-US From: "Chen, Yu C" In-Reply-To: <09a6d7832003733acbdf6bcc5f6f32b55a0caba4.camel@linux.intel.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SG2PR01CA0127.apcprd01.prod.exchangelabs.com (2603:1096:4:40::31) 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_|LV2PR11MB5998:EE_ X-MS-Office365-Filtering-Correlation-Id: 5349058d-7b4a-4fb1-45f5-08de3d2cb780 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|376014|1800799024|366016; X-Microsoft-Antispam-Message-Info: =?utf-8?B?WnZKMlZ4azNMMEpMejIxVnJsNnI3SFIzdzVKS3NUT25aUGN6aTc1bUpsdEF0?= =?utf-8?B?T3Uvc3pPaWtNYU5nYzVsYXV2bk9QU2lKTVFoTGZraGFVNE5CS1BVYjRTbDdz?= =?utf-8?B?ZGk0OHJFSlROMmVGZDh3bnlhMzRqV3Y3TWVpOFpQQjJwNDJLS05XMy83clEx?= =?utf-8?B?MXoyL1NObStnYjMzQTRnelVJT1hYbEgrbWtzaC9HU2JUcVNpWUlaOUhseksr?= =?utf-8?B?YmxHS2RRUW41TFQ1ZFI1TytOVUlNRFlMb1RpenJwRE4xMTZJS3ZMd2dob3Vt?= =?utf-8?B?SWNNMk5XZ3NSTTY2bWRiSnFGejZOcGNQbVNUcFNWM1lLVU1Pa3lPZmRMV1Bn?= =?utf-8?B?OUxiczhueEZxQ1hpbXB1ZzU2Q0x1dXp1TmgyMk83YldtOG9EREJaelNhUWtZ?= =?utf-8?B?cHR0MlNrQlVHSmtWUE9QVXlJRWNxSnhzaFo4SCtnR2UxT2dqeEkvSS94RHVU?= =?utf-8?B?czQxajY0NmpZV1BxR25SZGkzNjhIeHV1UmkyeDhGK2lkbUpNdE5LR040bmE0?= =?utf-8?B?elpyYmptU1U1S2M3bjQwOUx1OG56MlBOVE12RnliWDNNNThSV0xxeUsrRlBm?= =?utf-8?B?c1Z6TFd4azQzVFNBS3orREVUL09FTEo1MExEYyt6akQxVXFMRXBSRXZ6S2dn?= =?utf-8?B?OEZ3L1o2eE5yR1RrWElPaXRqUTNlR01tSzh5ejhGK3pUNjg1azliYXNabE9X?= =?utf-8?B?czFERy9Gcm9lbHl1U1BRcy8xWDZuSW8xeGtlNEIvTWNYNEp1V1E4K0lqNU5N?= =?utf-8?B?dStGYllyQ3A5S2IyVjBQaEdGOXZ0aU1vbWI3YnNBWjZ0UTd2YTVYVnVHb0tu?= =?utf-8?B?Si9KNzB6elRJeTRYQ2FnYSt4VSsvWGtoRlZjL0tDcGQ4MGxiOGppR09oNUZk?= =?utf-8?B?NWlCQkNITGtvVm4za0psMFQ1SitrbjNlWDFCa3V3Q1J6YUVIQk1RSTN2VUFH?= =?utf-8?B?RDBZamN2UDFnbmVpME9Nb2IzZzUremJGS3pFaUtHYStlUnMvQzRSSzdqVmI2?= =?utf-8?B?UlFySzJCcGVjYjhsc2M5ZnpIcFVPU2s3alVjVFdyQjdtUCt3VWVEbmdVZFpW?= =?utf-8?B?dXd0Uk0wK3NUVFJuNTJpMk9yNG1ZakxSQVR2QjRVbXF5TjY1Ukd5aWgzRDEr?= =?utf-8?B?Wk5EYno5SnRmN3RsODRrMDFpdkxnVzd6M0V4LzN0c0k4LzRmbGRFeXI3NFRs?= =?utf-8?B?U01XbTloaEpSMk9OUlF4Z1laWVlHMmc2R0wvZ2xYU2ZiZGlCNHB1Tkxmb052?= =?utf-8?B?NWhGbzRDSi9odTcyOHdQcVl3QW9mOVJoT2V6bWt4UXFJVlVlWjNvVnRUTWRB?= =?utf-8?B?S0V5WXp4b2VWM09id3pJN3BzT2VtNEgzZnR2dStYT1hDbDMyVFFnY1B3VEVL?= =?utf-8?B?YlFkREF3bU1qQ1lBanMrUmowa243Y0RJZExqUnFBWnM4K0kxdmdVUThtNm5U?= =?utf-8?B?RGpzRjBhT2U4bVZ6Z1oxV0lCcTk0N2l4N3FTS09ZU2pyVk5OWHRIaE9Rb0h6?= =?utf-8?B?QStnaVZCK2pzQndkdVJTWi9XZlJ2bFUyR3FEcUFqVENUQ2dtRjVsL2pHeDJv?= =?utf-8?B?VFBRNTB2S3dKelJFVVBvYVA2SWM0UlZNYXdiZWg4QzBnN2pRS1prUmZlRGNS?= =?utf-8?B?ajBrbWQzWFZQd0lQOG9aYmx2REJYVW1TWEg1WU95TjBOSnNIN0Z2MnF4MGdo?= =?utf-8?B?ay9sV2FHTFlBTi9qOEdxUlB3WE9nQWVKWXBZWHhQZ1h2dHc1MytpbnZGTU41?= =?utf-8?B?WTZuSTUwNWRjRkJNbmFUNWFmcHJHdGpHT3BBbnhiMmN4R2JkaTNhTzlEYlBH?= =?utf-8?B?d09mV3R3bEFGaittb040U2owU0RidmxjcGp3RlhOdW5Wd1FDM00zN3VYSUwy?= =?utf-8?B?eDF5bXVQc2R0VU4rWU5XUTBzREtPWU8wRlQrc0RybVROc2NJejFsNTArWStZ?= =?utf-8?Q?MXbChuXrPwLjokLNe20rCqb5vEl03VIm?= 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)(7416014)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QVpDTWRiajZFSDVLalhxbzJ5WnIvYWFkVkFrUkxScmtqYlUvSEx2Q3JHd1lV?= =?utf-8?B?Zkx3Z0EwNjJvNFFRV3FXRWhpVjhZV0VmR0VESmZzUXJIR2p3a3E2VzkzOHFS?= =?utf-8?B?b3RHekE0V2tYSUpwS080ekxYM3llbVdxRmxhSFZLVDFmTE92VVNITVlvUlhm?= =?utf-8?B?MzJqNUdneEdFd1hzcWlTd00rQlpUTEtINFRzU3J4dFhObnRoQ3RBQi84SVhj?= =?utf-8?B?Q3M1WVRheE5BenJyeFVCMmlpWWFraUZTWVhzMFJhaVJDWHFteXhZVUtLbVQx?= =?utf-8?B?NlV6Mm1MWUxMNG1MY0M0ZFRzeWZITStHME5CdjNYRUF4SGZLRml2OWkvb2t6?= =?utf-8?B?azJrcVpJU1phZlNCNHNxdEUzOGgvZDlPMjhBb3hjMnpNaVBGd3VKejF6RU5p?= =?utf-8?B?YXVvVzZWYTNNNHpIcHMra1JyYnZjTG1EQkxRYXpuZzdNdlhHVzYzOERSZ3BJ?= =?utf-8?B?NlJQZmdNMXArbUllL1B5Yy9kTzhkeXZ5T2ZtYlF5NEk2T1F3a20vci9HMHJz?= =?utf-8?B?bldEdWtMbm1lWEE5OVkyMUZFTXM2V3IrTVBRbVA5dndVNlZjV21vbjZHVktY?= =?utf-8?B?SXY5VGNmRXB6QTc1Q0V4ODQvL2QyZ09adDVnK1lrMm12NnBRT3AwN1hoRUpa?= =?utf-8?B?THpmSnVoVEx5VEZaMWdhamc5SjNRYjEvSXEzZ3IrVFo4ZGJnc1FXZ1lqbmJq?= =?utf-8?B?ZjZydm9oRUZXMVBFUnRSdHM1cXp6bzVaWGVxemxtU0I5Z3R3aUY3TEVva01K?= =?utf-8?B?QWliRUYzbFJnNldDSXcxLzBDUzhVeUdVS2tmMjRkRE8xbU4ybXhwSFAzZjB3?= =?utf-8?B?TXNOd3BTUWR2L0lsSW5HWmVkaDc4bitnU1NqVlB0M3NVQTl5ZFVMMHo3R0pU?= =?utf-8?B?eVpIaUhXSUFOeCs1YVVGUG00M2FjSWZsRFRZNk9Qb2hUb1dVZlBsQUFCNURu?= =?utf-8?B?b2VEVnhwSjZWZCsyMTJSaVNyS2pHY2E0ditYYng2ck8rbngvNmI2d1pLQm5j?= =?utf-8?B?SU1JWHN2dUV4dDQrY3Q4eFR5RnJTMlRHMVRaVDUzRWtsV0VURGhKaUxFRFZE?= =?utf-8?B?RTZ3OEZOeHNyTmhIdkh4QkRkd2k4eHNqNk9oby9BZUkxYmRiNXVYZzM3YlU4?= =?utf-8?B?NmMzbG03bUVLeityRVlwcnNTQlZNeDBvM2pwN1I2Zk9zb2o5cU9LSlNpT0Vn?= =?utf-8?B?U0E2UEVVM2paVmNEZGFKT1VYNnNmVUZDTXNYUEVhZGlQSUpXQldBNzhWbGJP?= =?utf-8?B?N0dEbkRRbnBzYndCdWpEakVOM0pVd3VRODZteVVkUFVuWGZhaHNjQkFrQUo3?= =?utf-8?B?N1kxMXlZYVluU3lrVGExejlRRUU3RkhkMFpVckpQc3ZyMTZSRGNETjh5MFlp?= =?utf-8?B?OVI3RjNMN043dzloaGFGM3VmUFRrLy9TTno4c0xBa0ZuS09aSGR1MFdqSVl2?= =?utf-8?B?RjJyUFdvYnNYTmkreXhwREdscFIrMEUwSGhqWFdmSUxZbHA1dGFMc2RtWUtu?= =?utf-8?B?UjlGU1BVeHVQL3hlTms2V1RPWmltVkY0L3NLbEowaGZWdlRkaUQ4Yi95VFlv?= =?utf-8?B?dVVmZ0NRNVlMN1ZjdkdnMkgyVE5aMThsTmtNWUkydVJMK0hhSjhKU2FOb1Ay?= =?utf-8?B?eCtyUDhSd2RIZmxQQ0s1WXVIMWRHQ2tBRVdGWDh4dVJ6RGZKbUd0a1I5ZTdS?= =?utf-8?B?eUtSL0NqV3B0Lyt1TGZwckFORlRDUFJmZmluMkRjU2FMVGdNSlFhK0pXeWpE?= =?utf-8?B?QnVMU3BJMGNacnJla3NPdXpIVzEvWWNZM1VEcHoyeHJoK0ZzM1IzWGszZlFB?= =?utf-8?B?Nnp0ajJmVnNPY0YveERMUVFDOTlVaFJ6OG5lLzliNmticmE0RnVvam8wUHp1?= =?utf-8?B?UFF6aXlzazRaSFVpNjhPaHVNK3N5ZnZGR0xaTFh0Y1Q0RUVaWVREZXFwbit4?= =?utf-8?B?cHJvVDA1d1poZFhCK1RjTDVtalNzU1pvTHJoT3R0ZnlvL25YazBxWlNxayt4?= =?utf-8?B?dm83MmcyQjR6UGtBL1dLcjMveSs1dnRMTlNPdW1VaVFESDdJQXRvTFRBOWtL?= =?utf-8?B?azFTZzEwUWNWWk9DTTdhUlR0akVXL1hHaEljd3oxUFV4UGtuWXBaMHZvV0dy?= =?utf-8?Q?ExuI8n8TeFEDJyZmcqbzcAGVV?= X-MS-Exchange-CrossTenant-Network-Message-Id: 5349058d-7b4a-4fb1-45f5-08de3d2cb780 X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB6020.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Dec 2025 05:25:40.2893 (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: Qvr0XUfbU3vrnpoXyO2r4jVJHzg30tmxmaJcNGCsSWU6J4jUglrA+lrMoO70evpo80XL2c5OQSP03e+bX862WA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV2PR11MB5998 X-OriginatorOrg: intel.com On 12/17/2025 3:53 AM, Tim Chen wrote: > On Tue, 2025-12-16 at 13:31 +0800, Chen, Yu C wrote: >> On 12/16/2025 4:49 AM, Tim Chen wrote: >>> On Tue, 2025-12-09 at 12:58 +0100, Peter Zijlstra wrote: >>>> On Wed, Dec 03, 2025 at 03:07:23PM -0800, Tim Chen wrote: >>>> >>>>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >>>>> index 710ed9943d27..0a3918269906 100644 >>>>> --- a/kernel/sched/fair.c >>>>> +++ b/kernel/sched/fair.c >>>>> @@ -1210,10 +1210,17 @@ __read_mostly unsigned int llc_imb_pct = 20; >>>>> >>>>> static int llc_id(int cpu) >>>>> { >>>>> + int llc; >>>>> + >>>>> if (cpu < 0) >>>>> return -1; >>>>> >>>>> + llc = per_cpu(sd_llc_id, cpu); >>>>> + /* avoid race with cpu hotplug */ >>>>> + if (unlikely(llc >= max_llcs)) >>>>> + return -1; >>>>> + >>>>> + return llc; >>>>> } >>>>> >>>>> void mm_init_sched(struct mm_struct *mm, struct mm_sched __percpu *_pcpu_sched) >>>> >>>>> @@ -668,6 +670,55 @@ DEFINE_PER_CPU(struct sched_domain __rcu *, sd_asym_cpucapacity); >>>>> DEFINE_STATIC_KEY_FALSE(sched_asym_cpucapacity); >>>>> DEFINE_STATIC_KEY_FALSE(sched_cluster_active); >>>>> >>>>> +/* >>>>> + * Assign continuous llc id for the CPU, and return >>>>> + * the assigned llc id. >>>>> + */ >>>>> +static int update_llc_id(struct sched_domain *sd, >>>>> + int cpu) >>>>> +{ >>>>> + int id = per_cpu(sd_llc_id, cpu), i; >>>>> + >>>>> + if (id >= 0) >>>>> + return id; >>>>> + >>>>> + if (sd) { >>>>> + /* Look for any assigned id and reuse it.*/ >>>>> + for_each_cpu(i, sched_domain_span(sd)) { >>>>> + id = per_cpu(sd_llc_id, i); >>>>> + >>>>> + if (id >= 0) { >>>>> + per_cpu(sd_llc_id, cpu) = id; >>>>> + return id; >>>>> + } >>>>> + } >>>>> + } >>>>> + >>>>> + /* >>>>> + * When 1. there is no id assigned to this LLC domain, >>>>> + * or 2. the sd is NULL, we reach here. >>>>> + * Consider the following scenario, >>>>> + * CPU0~CPU95 are in the node0, CPU96~CPU191 are >>>>> + * in the node1. During bootup, maxcpus=96 is >>>>> + * appended. >>>>> + * case 1: When running cpu_attach_domain(CPU24) >>>>> + * during boot up, CPU24 is the first CPU in its >>>>> + * non-NULL LLC domain. However, >>>>> + * its corresponding llc id has not been assigned yet. >>>>> + * >>>>> + * case 2: After boot up, the CPU100 is brought up >>>>> + * via sysfs manually. As a result, CPU100 has only a >>>>> + * Numa domain attached, because CPU100 is the only CPU >>>>> + * of a sched domain, all its bottom domains are degenerated. >>>>> + * The LLC domain pointer sd is NULL for CPU100. >>>>> + * >>>>> + * For both cases, we want to increase the number of LLCs. >>>>> + */ >>>>> + per_cpu(sd_llc_id, cpu) = max_llcs++; >>>>> + >>>>> + return per_cpu(sd_llc_id, cpu); >>>>> +} >>>> >>>> I'm not sure I follow. So partition_sched_domains() first calls >>>> detach_destroy_domains() on the old set, and then build_sched_domains() >>>> on the new set. >>>> >>>> Do detach_destroy_domain() will do: >>>> >>>> cpu_attach_domain(NULL,..); >>>> >>>> That is, it will explicitly attach the NULL sched_domain to a CPU. At >>>> which point I feel update_llc_id() should be returning -1, no? >>>> >>>> Then later, build_sched_domains() will set a !NULL sched_domain, at >>>> which point update_llc_id() can set a real value. >>>> >>>> This should then also get rid of that weird max_llcs check in llc_id(), >>>> right? >> >> The check for max_llcs was intended to prevent out-of-bounds access >> to rq->nr_pref_llc[] at multiple points in the code. >> Since dst_llc = llc_id(env->dst_cpu); — and while the LLC ID for the >> CPU is updated in update_llc_id(), this update occurs before we reallocate >> the nr_pref_llc buffer — dst_llc may end up exceeding the bounds of the >> original nr_pref_llc buffer. >> >> For this reason, we added a check if (dst_llc > max_llc) in llc_id() >> when attempting to access rq->nr_pref_llc[dst_llc]. >> >> However, I agree that the max_llc check seems to not properly integrated >> into the current patch: it should instead be placed in the 7th patch, as >> this would better illustrate the rationale for the max_llc check here: >> sched/cache: Introduce per runqueue task LLC preference counter >> >> In the 7th patch, we actually increment new_max_llcs rather than >> max_llcs — meaning max_llcs always represents the "old" number of LLCs. >> As a result, there is a race window between extending the rq->nr_pref_llc >> buffer and updating max_llcs. >> >> >> @@ -714,7 +827,7 @@ static int update_llc_id(struct sched_domain *sd, >> * >> * For both cases, we want to increase the number of LLCs. >> */ >> - per_cpu(sd_llc_id, cpu) = max_llcs++; >> + per_cpu(sd_llc_id, cpu) = new_max_llcs++; >> >> return per_cpu(sd_llc_id, cpu); >> } >> >> >>> Thanks for pointing this out. Yes, we should take care of the >>> attachment of NULL sd. Will update the code accordingly. >>> >> >> My understanding is that, if the sd is NULL, it is either because invoked >> by detach_destroy_domain() for the old set, or by case 2 mentioned in >> above comments: >> Say, CPU0-CPU95 are online during bootup, the boot command line is >> maxcpus=96. >> Later after bootup, the user wants to bring up CPU100, the LLC domain for >> CPU100 is NULL in this case(due to sd generation), and a new LLC should be >> detected. >> >> That is to say, when we reach update_llc_id(), there could be 2 reasons >> for NULL sd. For the detach_destroy_domain() case, update_llc_id() >> should return a valid id without increasing the max_llcs, because of >> if (id >= 0) >> return id; >> And for the latter, the max_llcs should be increased. >> Let me double check on this. > > The issue is we could offline all CPUs in a LLC and online them later. > In the current code, we will assign their ids all to -1. I suppose we don't reset the ids in current implementation, only the first scan of LLCs will reset/initialize the ids to -1 in build_sched_domains()? if (!max_llcs) { //max_llcs is initialized to 0 during bootup for_each_possible_cpu(i) per_cpu(sd_llc_id, i) = -1; } > So on attach > of CPUs again, we'll be assigning a new LLC. I think the proper thing > to do is not to assign llc id of the offlined cpu (the case where sd == NULL) > and keep the original llc id assigned. Then we should be okay and not > increase max_llcs. > This is the current implementation because we don't assign new ids to CPUs that already have an id(no matter it is offline/online). thanks, Chenyu