From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.14]) (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 B8D9D2309B2 for ; Sun, 15 Feb 2026 14:26:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=192.198.163.14 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771165579; cv=fail; b=JNdJXhK7od9OK6edETc25iXI+ieB3ObA1dZBABDbZcHjCOh9NeHRl3Q5hutlZF44VmtNyvYrLY7PUSaXUqGumR26M3L5InXgx+apb9/oYlkiTjtFuznVoMEWa+AOKadG1T2IkQ1oIQdwxRtexAAPwpXJLK7HDVo372XJedLBwxM= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771165579; c=relaxed/simple; bh=SgEUec+/5qW8oP2rUvDbpGzAkQ6LbPQ4LLttn/jyKZk=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=fvMN8UKkSPD18c3DXF5fSHPspPYtK4MS5Byt8egCdQshg+vEnVC2qdKz/rJGAPFbSaa8eY/lgEjPLQxoZqUSneidxId1HgqYw2VN3UD7WBHn8IR+O+zPGxjrahJMNzpyYwdvVhJKtACV8soFgaK8p9r6dE9JoBEzGxhJhH0Lwvo= 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=JK4mnwvM; arc=fail smtp.client-ip=192.198.163.14 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="JK4mnwvM" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1771165578; x=1802701578; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=SgEUec+/5qW8oP2rUvDbpGzAkQ6LbPQ4LLttn/jyKZk=; b=JK4mnwvMh/g0VyUK89JHQsQ/F9XPCeEcPYxFM1iZjtMr89+8rhhemXHC QIesDT0wTPe28GDqui2v5AMiibs9Wd1PL6htJyU5UlldYJGK3mX4+nbdN zhT1hrfV/PaT33zZEF4tyRKWSZpRYSfPGknOkDwf6UlBeLIhxE1lTPBtV XTZg5j0HLEsjJLtBzhN0H3sf3vLSgsTT5Co1mI8Pis0hYCbHTylaY6hw4 k+UCWcHb2MLpB7ItGPvZY2Y/KElbcC4sjX9/2672X78MGzwOIzc3X8yZw CI2oS8SfQK1B5eIJxR6zK3h6/Fd9DigTJVBJcHl7NRcVTYHGZaZEEZ/fH w==; X-CSE-ConnectionGUID: FOqGwA2YQOyhsxK9CM3Dww== X-CSE-MsgGUID: iU2yOvTQRjy5vudD5QaHMg== X-IronPort-AV: E=McAfee;i="6800,10657,11702"; a="72344221" X-IronPort-AV: E=Sophos;i="6.21,292,1763452800"; d="scan'208";a="72344221" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa108.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Feb 2026 06:26:17 -0800 X-CSE-ConnectionGUID: xjVQTGVUTc+4WQgjyZDjtg== X-CSE-MsgGUID: mzo3q4UnR3ejMPY6+8caow== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,292,1763452800"; d="scan'208";a="243960415" Received: from fmsmsx903.amr.corp.intel.com ([10.18.126.92]) by orviesa002.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Feb 2026 06:26:17 -0800 Received: from FMSMSX903.amr.corp.intel.com (10.18.126.92) by fmsmsx903.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.35; Sun, 15 Feb 2026 06:26:15 -0800 Received: from fmsedg902.ED.cps.intel.com (10.1.192.144) by FMSMSX903.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.35 via Frontend Transport; Sun, 15 Feb 2026 06:26:15 -0800 Received: from CO1PR03CU002.outbound.protection.outlook.com (52.101.46.44) 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; Sun, 15 Feb 2026 06:26:15 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=s6XRzE/tcptiu5xCwhca0py8EQrZbYmMv96MxY99d+mi4D0wgslfAq6P5tnoUz4GVDEXUAMR0B5/ZFCPameDkcASvIwqJCB3aGMLdHSLxSJBXXxtPTMrmeMDr5DeHlhFNOop4LnCkCklxLv+MoH3Xde5Y2eHcT9LmYg7Dr9AkL2dgj8BQ2l2cVk/qm4G+H5Jjum/6IZhaSUoQ74lzMMVFm34c/PPBpPXk82biNSKpNb5NFxyJ8Q8PGo8zzSnNBKUE86FSI07MAf4SOA9h6a2Caea4FQIFeVkDVKyLopuonzvwEGEfSXYXqOaPky75pite9cnppqMU+dd+Mb1hTeV3w== 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=+wKkq4e62ouCEvmRXjrhLHfF/pWKlENMXzh9Wv2SGOQ=; b=NTzewHZz1Rxd226V5Ywe0apHpkGjU6JbP7Q8DKtiYid6V+/24C49TxtDtsgeZMTP8yv9AJE06BGfuKGBiuTQaLbe5SKkFXDqIRdOYfU8ef2zJIy59PeihX/B3ISeVGoGuRtGQIhfAUAcMmjZa+Ic2iw09XQXJfhzhfffuOOs4401sXTKVhO9K7zpCvMo7TG0QaneOxCOaW26mDjqxc8Vjhm/DvmA6gpQ22TzSjWRb2s16SCdliQDF5xuDGRfufPi/6lULheK/Z0ESAMUFFz3P7Iys4Lvx2rY7vEUrONe3xdF2Iy9HAg/QPEs/V4CMcAy42ON4Q9UtaBZxkFItYxm7Q== 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 PH0PR11MB4774.namprd11.prod.outlook.com (2603:10b6:510:40::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9611.12; Sun, 15 Feb 2026 14:26:13 +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; Sun, 15 Feb 2026 14:26:13 +0000 Message-ID: <54e60704-b0f3-44df-9b83-070806b5a00c@intel.com> Date: Sun, 15 Feb 2026 22:25:57 +0800 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 04/21] sched/cache: Make LLC id continuous To: Madadi Vineeth Reddy CC: Peter Zijlstra , Ingo Molnar , "K Prateek Nayak" , "Gautham R . Shenoy" , Vincent Guittot , "Juri Lelli" , Dietmar Eggemann , Steven Rostedt , Ben Segall , "Mel Gorman" , Valentin Schneider , "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 References: <60a05a3f50d14a7bf3b968f62cca87893c5c552c.1770760558.git.tim.c.chen@linux.intel.com> <437fef08-cabe-461f-a2d2-4bc385e9d513@linux.ibm.com> Content-Language: en-US From: "Chen, Yu C" In-Reply-To: <437fef08-cabe-461f-a2d2-4bc385e9d513@linux.ibm.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: SI2PR06CA0002.apcprd06.prod.outlook.com (2603:1096:4:186::10) 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_|PH0PR11MB4774:EE_ X-MS-Office365-Filtering-Correlation-Id: 7239fd57-8447-43b0-a67b-08de6c9e2c06 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|7416014|376014; X-Microsoft-Antispam-Message-Info: =?utf-8?B?SUF5UlJoRDJMSnpZL09BS1dhdGRUN2pSbTIyTWczc0trVE1mUGIyNWhkaE5R?= =?utf-8?B?NVU2SkZCWW9xRm5oZzVQWkFPWTJYckZxNDVReE1PU3F0OVA3WENYNWhKbmli?= =?utf-8?B?aUZoUU8xVmFiOWt1cHhlZEUrdk9XMDZ6RWZrdjBHTXB6dnZYbGdPcnZERG9K?= =?utf-8?B?RmpvczVudmgzc2FFWlR4c2tnbXU5VGFHeXVKaGdtWHc1WWtvZkVIT1hCQU5t?= =?utf-8?B?S05EdnVhZXV1Wlh2Z01MY3QrdmJxQmM1a204ZmtmLy9rN3BJQXpOWXBSNVp4?= =?utf-8?B?M2lQZEo1K0Z1c2h2M0N3b1pBa1RiUzBPcGZhSUN5M3loZS9IY2t1QzVKMU5O?= =?utf-8?B?OWFTcFVaQWFMcUw3TnhBYjJ2V0Y2UlNUM2FnQVFFckxxTlhsSllNUk9rVmJj?= =?utf-8?B?Rm9GWHJIWjBzNEJRZTQ2WWd5L2U2UjFIVHlYa3VGUjF6a0VLV1hiR1RxNWFq?= =?utf-8?B?VnkxS1lwWXZYVjNmS0N0UmlpVUtpbjlHMHpBQmNzVlVFNmFGd0RRYUlsajRj?= =?utf-8?B?OVV1S2Y0M0IrSEI0dEdIbW5pTmJrb3RzcER2WUxvVEo2bTJOMU5PQnFZckU4?= =?utf-8?B?Z2ZSRUJrbXkvRlZPTi9ibU9yYi9nRmJHOWtCTWcyeE5pVzBNb0l4bEQveEJ3?= =?utf-8?B?YllCaHJVSEJ3NG4xMmFyRDVHWnZtNmg2ejZraFNLL2c5dUNiTGFCU0xySkJ6?= =?utf-8?B?c2cyMGRaK1d3dHcvRGxaYXpxVkROTFJLU3gxbXNrQkJmblY1Yk1xOFplbW4v?= =?utf-8?B?MUtTR2pqWFFVbmhKcDZEU2JuRGMyN0RKOTMyVHFJSkJqSFllYm1PbjdFK2Nq?= =?utf-8?B?VWlmcXZzaXJhZWhMaUhvN3hQeE9BVXhsRmR6bC9FOUlpOUpCWlREQVROM01Y?= =?utf-8?B?RGtDTnh0ZUZmMFlkaEwrQmNlYjlYVVNkZ21GcitTYWFkNUpYWmhZTjRaSXM3?= =?utf-8?B?TWFTbUNnNmxBM2tLSWZVVllGcnRndHJBR2dHSUZxNDFnVVhKa3ZyRENJelVU?= =?utf-8?B?Rno1ajBoN0hiY2ZoQ3IwRWE3cG9JYTd4Q2ZWcXNRWkFGZkZvbzFUcWxJdFVM?= =?utf-8?B?Vmcvc2k3ZWkxTXByM29kbkRFdU15bnExM21vME91VlpxNlRLbzhDNm5rVDNL?= =?utf-8?B?bFZIUmVBWmlVN3pFU2NqZ25IVXFrblpaNmtOMVhTd2IxTHpha3VUUy9rZlRB?= =?utf-8?B?am11VDdZazhOVXpTV1JJNFlEWEY4cTN6czBnZmJIWFNtRVNCY2I4NjYxRWNx?= =?utf-8?B?KzBwVUlyZzBHamo2KzZrUmtSR2x2aVVhNFlrMndaRXJSN1RmWFNCSjJIdGxB?= =?utf-8?B?SzJSTUNwSUZKVzZCbEF0czJrY3VmRUNCeC9uOFIzODZUR1VxbTRnc1kySmxs?= =?utf-8?B?ZzlGNEo3TWswUDM0dDRwYTZFZFFkVmZQcEZHdU9KZ2xueEFUeDNLcjdCU3pX?= =?utf-8?B?R0hxY00vczVOK3BMSXVXOFBOb1pCV3ZKSjVtUzVQS3ZKWmFoL21UZFZvZmNO?= =?utf-8?B?clEzTnl3MGF3Z1ByQ2hTSWlxUnJLVkVRNEZkUUlqbE5ncENXOWdRT2VscnBa?= =?utf-8?B?V3huWjdPdXhDTjVkcnZwUmF0cGJqM3lvWWswZzVnK3lKR1FJWC8xZnBYa3BZ?= =?utf-8?B?UURuWThZK0ZxSExGNTJ6NG52anNQUFdQdTJEYmNSL21JaVpHRzQrOTJkTlBQ?= =?utf-8?B?MU5QeFVmS1JNUk1yWTNhbytyZHZnSnJnWlcvL2Zxc1pkbG4zcWVISmlSOGk0?= =?utf-8?B?amRXRUNHT09LQktPQS9pL0E2TUNGSlpVd2JHY3VVdkprMlR1RW1nbWdYNGNn?= =?utf-8?B?NE1pREZNZ3Z1cmJzUWZyaS9zV0d6cGtHWVpVZ3lCR1NENjVBb2FNbTNXaVBm?= =?utf-8?B?dlhPV1FSNUVqUk1FWmhjZXdjZ1dvUzhzVFdKUzRoZm5rMlhuOE5uY0V5QlNi?= =?utf-8?B?aG5US0UxYmduditXTzJleWZ1QzRycGw1akZDV1BmQjNXdHhMUDE2TGt3TmVs?= =?utf-8?B?b3kvVG1iOW5sTDNRZ3hCNlpMa3hIdlBRbFpHaERlWDVISWhZaUFyR092L29D?= =?utf-8?B?N2hjRU1ZUTg4SzFsOGZSUGhWakMxdlJXYTJKTVUrSnptZzdmdCtQNkpLando?= =?utf-8?Q?hB0I=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)(366016)(7416014)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dUNZUCtDbHZIUU1VOFFaSzYrVHZNR0hrQTMyM0xwMkE3dEFFQzlmNUxFN1N5?= =?utf-8?B?UWFueXZpVUlHZURhenhtV2xSRjJwRnBuanlDcEpvZTRZTWdyN0FIK3ZRQ3F3?= =?utf-8?B?K25wTGt6aEI0WUFtZXZMNVFtU3RSNzRuekFaOC9MQThNSE9sT1ptMVBHd0I0?= =?utf-8?B?bHFhMGFsZFd2cnUvN2wzRU9mVmNsdU0yWFhrdVFYV0NmRXp6MGlWTmJoZzF2?= =?utf-8?B?OUxxc2l5V1k1dlVsejdvYXFNQTl4N0hvNE05SE8wQ0E5azhsV2lCNWN0eDBO?= =?utf-8?B?RHFVTVVTK1NqWGFRVWk3djRmV3YzSTdncjZxdWVKVlc4eWthU2FCV3dtSWdx?= =?utf-8?B?bVBiVitXejBEOUNpeVJ3clRUamhyeHhXMkhDK1NmNjNFVlh5Tjl4cVRCYWZW?= =?utf-8?B?bW9kZzRjUktTZjB6YnhuQXNIUDNXWG41ZFIrVWROMDlGM2QyU0Zoa0FLMHp0?= =?utf-8?B?dHZtVzZBWmY5QkNsTW5pdEk1NHhuUUdNc0paS2pUNTRFRjR2c3A0UFVxY29x?= =?utf-8?B?UXk3akNSNW9MRWhXSE5mM2hDNWNhdi93ZHVnNTB0REJ2YUpwWHluK2JWdURB?= =?utf-8?B?Nm13VWxlQzVWRnc4b3Q4bUx6dk5lbU9YR0dtV0pNeHlyTUM2ZXg4dlAwZkMx?= =?utf-8?B?UzBTRTJyK2c4b1lmbXozeWd1MVQzV0RTRjFYWSt0a2hoYnFDeFd0SVIzRWFm?= =?utf-8?B?NHRuaVk0d2FhaWVGNmVjVHQ0cUdlTmRyWkNhR1JrOEFidW9leGdvVGxUdkh0?= =?utf-8?B?S3pBYTZyOWZDWHZkV2Q2cXlLT3N1c2dvSkdMZ2Y1SHNRb0RPTVZ3QUUwVUhT?= =?utf-8?B?WGt3QWZZTW02T1VVb1JoVHNlUW1xYmNkKzFIWHpWVTBNNk1rcGw5Qy91NFVt?= =?utf-8?B?bFQ2dWovOWEvVFVYbVRUOE9jMnREQUtrZkQ1enNpNmNScnBiR0FKd0lObnBE?= =?utf-8?B?d0F3L0k3OERmdS9NWnprcnJYTDRacXNmdHFVaW5wK1QzQmZCNkJyRVpEamo3?= =?utf-8?B?WUVaeFU0S2JpcGxoR2s5a2RlMzF2VWYzRy9HdWNxS2VwcExJakpPR1pEVDF2?= =?utf-8?B?RXNZY0wxeURCR1FVTkZXUG9ONDVkTTFKakpzbDMxMlJmVmYwQ2lXcVE2elZx?= =?utf-8?B?em9hZHFoL20yTkhnK09sUVF5WVFKZlVJYnpTKzFFSktiYjhpUUNySmtYSzB5?= =?utf-8?B?c0RIZm5XSFpzOXI0dzl1YnhNd0xLZGFCc2RjZm5aRjBTMGExSWhQUHYrM3ha?= =?utf-8?B?S1JxVEEwWE0xOUZlaHRxZmZFR3NwUGlqSzgxcGRPQVRwZU9NVXhjb1FxaVpP?= =?utf-8?B?UGllNXlmcSsrbXdreEQ0eGppbHBoSEJna29jM0ZzVkhkY1NmdnNnNnlZVnpw?= =?utf-8?B?WXM0Q1JURVowRnRUUlJqbVZ1emtaZXZleUR6aEpnMlE1VE55K0dnVlI3ZWtU?= =?utf-8?B?MnZ3RG1Zb3JWS0loUnRSM04rNFE4ZWt1eHJCbE9jZi85dzRGbVJJV3NNcC9x?= =?utf-8?B?aXZjU3BYNTdwblc4USs5NElQZmduelBHN3dUQmZDYlhqY1U4V3RHYkF1MmRk?= =?utf-8?B?SEVZTHFlcUwydHo1N2dSZHlPQXdKeklYNURYbnRuV2xMcGRwUWdmZ1h6dEE2?= =?utf-8?B?SVpzUmVmSWZIYy9HSk55dmYwMm5KS1FybStYRlE0NmtKTVMwZ2M5VmVjOURD?= =?utf-8?B?OEVOQWRIdFNyS0ZIZmxzdEc3YnJRcncwbW81MkpDVEgzakM3NXpldFB4V2p4?= =?utf-8?B?N3JVelUvTG8vVk5wQTJrZ1ZnYVo4KzJweFJuNVpBTUZ1eFZGVjRRWVN0SXR6?= =?utf-8?B?VWdZaENoaVFHcG55MmV4b1M4MHlQM2p1ZHMyUXR5RGh4OWcyVjJGdENpZWNl?= =?utf-8?B?TlU1TmpXUlZJT2lXVlBRdG1WNjFMVXg4RS9mbzkrNmV1SG9PUHhRVm10QXpj?= =?utf-8?B?WWJhVktnbDN0ZGlmS0cxc3lhNThGS0hld1BzQlNDWTFEVUtlOXRRTzB1T0Fn?= =?utf-8?B?Z0FiNDhSc0doRU11d3hhYnJRek5VZDRTMjJ0RnRLdUl4UHJiTHppdk8zSHlC?= =?utf-8?B?aTcycE55enFmcU5GRVpjbG1iekVMdjczZFBxOUZHY25lQmlmc1RlY0JvZ0N6?= =?utf-8?B?T255blViZk81MEU5VDhSYTJXY1Bra2RRd3JNaitDSThSOXFDeWptcEdTWitl?= =?utf-8?B?UXhLWDlabVduSGdlL3hFaDRFZ2hJbEZ6emN1aGpZeWVTZXltbTNHeTVoTlFz?= =?utf-8?B?QUZEVC9PZ0cyYXlXTnk3Rjd2UHErb0l4WXNBMWc1M1MxbHBrYXMwc08ybkJB?= =?utf-8?B?cGN0dXRsQ2FJcjROZ25LQ2JDS0FXaVFURG50eC80U01PM01DNm51QT09?= X-MS-Exchange-CrossTenant-Network-Message-Id: 7239fd57-8447-43b0-a67b-08de6c9e2c06 X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB6020.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Feb 2026 14:26:13.5588 (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: 0zMCHc2vr2Hx0ey8j8LaiLMbZoNTcy1ycA016pHLeDL162PxpDSIDDc5721X5P6a5Iw8L/5eiffWgnsZX3yZbw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4774 X-OriginatorOrg: intel.com On 2/15/2026 1:53 AM, Madadi Vineeth Reddy wrote: > On 11/02/26 03:48, 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. > > tl_max_llcs is never reset across multiple invocations of build_sched_domains(). > While this preserves LLC IDs across normal CPU hotplug events, I'm wondering about > scenarios where hardware topology changes, such as physically removing/replacing > CPU sockets. > > Example scenario: > Boot with 3 LLCs: IDs {0,1,2}, tl_max_llcs=3 > Physical hardware change removes LLC 1 > New hardware added at a different position gets ID=3 > After multiple such events: System has 4 LLCs but IDs {0,2,5,7}, tl_max_llcs=8 > I agree that keeping tl_max_llcs non-decreasing might waste some space. The original motivation for introducing a dynamic sd_llc_id was mainly that a static sd_llc_id[NR_LLC] is not suitable, as we cannot find a proper upper limit for NR_LLC-an arbitrary value for NR_LLC is unacceptable. That is to say, tl_max_llcs serves as the historical maximum LLC index that has ever been detected - like other terms such as CPU id. It is possible that the number of available LLCs shrinks due to CPU offline after boot-up. A value of tl_max_llcs=8 indicates that this system once had 8 valid LLCs. On the other hand, dense mapping is a side effect of dynamically allocating sd_llc_id. > This creates gaps in the ID space. However, I understand this trade-off might be > intentional since physical topology changes are rare, and resetting tl_max_llcs and > all sd_llc_id values would rebuild IDs on every invocation of build_sched_domains(). > > Would like to know your thoughts on overhead of resetting tl_max_llcs and sd_llc_id > so that IDs are rebuilt on each invocation of build_sched_domains() to always maintain > a dense mapping. > The current implementation is intentionally kept simple for easier review, and I agree that strictly enforcing a dense mapping for sd_llc_id - by recalculating the actual maximum LLC count (max_llcs) whenever the CPU topology changes - could be an optimization direction once the basic version has been accepted. I assume what you are suggesting is that we could reset tl_max_llcs/max_llcs/sd_llc_id for CPUs in doms_new[i] within partition_sched_domains_locked() - and then rebuild these values in build_sched_domains() accordingly. One risk here is a race condition when modifying the llc_id of a specific CPU - but off the top of my head, valid_llc_buf() should help prevent out-of-range access to sd->pf caused by such races. Thoughts? thanks, Chenyu