From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.7]) (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 738B81E4BE for ; Sat, 21 Feb 2026 02:48:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=192.198.163.7 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771642137; cv=fail; b=chVN95ED2EzUF1eTbnNb/6jxeSHS9Ni4PL/LCN5GvqP1Q5UyvjYtSrqVRF4jcSS6pmLRdVhkJEsw3BEpE6kGDIFtBsT5NIGKMncUkUcgK5xllyW/y46uGuEhxd5MiC+Z3YtlnF6XHgOqwd2Ho35FKRhMikIUoqrOO/k2oUB/Iq8= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771642137; c=relaxed/simple; bh=KWD1lBViKh7ZzCVkZn4waJ4LBiODwxf7HhBPLGYj73E=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=lec1H6RRYiIyOAEg+1dD1eE6tFu5h3mU5Tw/0afYy5TqS0NbeEqnC620L3DAO33WOCXt8ffletPVKmshrBgeAo2LpYFu5E5AuKDN9E5r4/XmiqybGnTBRtjuSkMAT0p9Naytks533FfFFFaFupDZW7zBNaqM5qCcxrM1ZQjBYes= 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=WXEHS3oP; arc=fail smtp.client-ip=192.198.163.7 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="WXEHS3oP" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1771642135; x=1803178135; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=KWD1lBViKh7ZzCVkZn4waJ4LBiODwxf7HhBPLGYj73E=; b=WXEHS3oPt0Wtjg7UeIqXCxT37rzMuW3S7msdli1YpvmJfmIe+z06nDXv 52AQA9AQFkXRxwVg2JYAWS2RlnaqcTscc4VCqO/IosKi/MFjkafILB4Aq oKO5MlNMl6EzMutaZUws2ZwiSK5H01tmfewY984/VastXyHCZd4whKwJp yV4xHipa6Xgu79iEyykVxXTDp1tiWZKkUoqQDqtsm5gggi7ShQdDBTuZt g2ribFECF3gjaoGxu70pGFAutPUU/iQfiu5SicdCUwduQMjK/0iPGKXYz kbIWeT4xL5PiB6uD7yqXv+nxb4IMS9TQbQ10rigF3quxQl2DfUXQ4pb1E A==; X-CSE-ConnectionGUID: 8AXkIl9ASmKd0y5HV5dEXA== X-CSE-MsgGUID: VoxmxahtQLmUHWHQ8SLhYg== X-IronPort-AV: E=McAfee;i="6800,10657,11707"; a="98195728" X-IronPort-AV: E=Sophos;i="6.21,302,1763452800"; d="scan'208";a="98195728" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Feb 2026 18:48:54 -0800 X-CSE-ConnectionGUID: fMV2BMqIQkOAuSujRMZPog== X-CSE-MsgGUID: R8HoMfZiRSq3B9qVHLZm0g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,302,1763452800"; d="scan'208";a="214863356" Received: from orsmsx903.amr.corp.intel.com ([10.22.229.25]) by orviesa009.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Feb 2026 18:48:54 -0800 Received: from ORSMSX901.amr.corp.intel.com (10.22.229.23) by ORSMSX903.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.35; Fri, 20 Feb 2026 18:48:53 -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; Fri, 20 Feb 2026 18:48:53 -0800 Received: from PH7PR06CU001.outbound.protection.outlook.com (52.101.201.48) 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; Fri, 20 Feb 2026 18:48:53 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=p5xr7mAJUHm5MZyx2b0q08RTufAV0JcYdBjJSDt0BD4kWz/lR/boc7/M199GQvM6+nnee3SyzQnsrODeuWiS+H3z29tYvf4tTAD4GjQdams0TXeY9S+L8MsroUBIPKN1bF0CTyeqMG8sgBlM496cMpfFj2+keE/xRww0n6hxfqU4tQ5sYqh9q9J4DHw0qxed71vI/c0YQ23iwTHGDOEb/DzpgXZNJSZHSCja5ntle0kevBUsi1g/XF5wA4lGkZ7D5xdgG0KQaYq8b8Tp7N77kpd1MkU4v42FHbbLnUMXfamHsNJQWoN/f8wk71I7+ox99qJHfHrxjH+vCjnwKAmawg== 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=GEN6GLuPEiTvSv3iIoFEqBUPbd3qssMhflWot+rkbwE=; b=q1YkZqFNGBZQjPJplLCMUx4LYSxCxsn3VVDygZLgkCAIu08XKe58HM3uwyq+uBav0PezqPft673wb5S9JU4jdrwoEQqbpXAkCqS3yXtLFfswCkQwLVyzOOx4b80GmvYPh2HxEgC6u6VlQEoLkgmba04khg6UDdZqihyd0W0GlmE8jM4k2LGVJqh2Hkz4pwOMsC41cI+hEMfDUDa4/QhAjNjNrBVR7AuPj4RaQsAHfDIll/VYfuWvMWekUWqEBAwdeIddIqcM8rPjn0/vwuEeEUV9CADVcOyS1CJ6zbmsyJJvNQwK1LL+uRfAeVLbRLDHUToRQpnkQbKrc81m7zlcIg== 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 SA2PR11MB4907.namprd11.prod.outlook.com (2603:10b6:806:111::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9632.17; Sat, 21 Feb 2026 02:48:51 +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.015; Sat, 21 Feb 2026 02:48:50 +0000 Message-ID: Date: Sat, 21 Feb 2026 10:48:38 +0800 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 00/21] Cache Aware Scheduling To: Qais Yousef CC: Peter Zijlstra , Tim Chen , 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 , Josh Don , Gavin Guo , Libo Chen , References: <20260219140828.a7pyzupun7lsdw34@airbuntu> <20260219144108.GI1282955@noisy.programming.kicks-ass.net> <66a23acb-973e-4987-a006-18c50e18d3aa@intel.com> <20260220032527.iing4vb2gylk5o5z@airbuntu> Content-Language: en-US From: "Chen, Yu C" In-Reply-To: <20260220032527.iing4vb2gylk5o5z@airbuntu> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: TPYP295CA0028.TWNP295.PROD.OUTLOOK.COM (2603:1096:7d0:a::17) 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_|SA2PR11MB4907:EE_ X-MS-Office365-Filtering-Correlation-Id: 51be0c0d-613d-49a0-e5e1-08de70f3be65 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|366016|1800799024; X-Microsoft-Antispam-Message-Info: =?utf-8?B?OE5DOGd6VDZid2FVY2NiZW5lSjhqaXZFSzNhZmVydjg1T0taY29vZVZRNEM3?= =?utf-8?B?YlZVODNDZEFDVzZZTENqMmdIc2s1RFZlK0J5S2YxeXY4Qlh5NTBhMkdmQ3hr?= =?utf-8?B?WG01alhqTzNLZEQrTnM5eXJ6VEdTcm9Bb28rZWE1ZG5peUlnbTU4YjlBaldm?= =?utf-8?B?ZWZyeTdrMklteDdvWld5Rk90MEROTjZ0Y2JTY21EN0dySXFZZHFaOElON1lx?= =?utf-8?B?ZWl5YlVmelptRnN2WStGeXFyVTJ2SVpnZzc4VUNHM3dmRVZiQVZiUHFNSU03?= =?utf-8?B?S2pVQUZodWZjMWNGVWMreEVsZkljMnJqWGlQQVNtM2o2dE1vcmpZZ0J6Vk1n?= =?utf-8?B?KytjTWJoUmlaUFVnNDFxNmNzd00zMFZlOTF1dC9WajZGQlV3QXcySUdIMnBo?= =?utf-8?B?S2pPcEQyczBJcDUwTmprVTljU3VjNkNCQVVwcUJnZVR6WWZCcU50QWJSYlFS?= =?utf-8?B?RFNJNHgrZmRpbWdTMm5HRHltYSt4MVpBWmdyVnc5RU9CTnVBU3ZoWVMxa2d2?= =?utf-8?B?VDMyL0VEUVlJNVo1Rjc3ZDVNQkR3U2gvRThJMHB5a29OUHExS3ZCTDh0Qk9D?= =?utf-8?B?WkhKa1YyeDE4MmZCMmxSNHl6c2JZVnRFYThwS1Ura3BpM2hobXh2ZkNucWtr?= =?utf-8?B?MTh2U09FY2hCQTdxSllCQ2ZJdEc0dEJhNTMzMUpwY09zaC9iaG1xRmtYb2t3?= =?utf-8?B?bzNCTlk0eGZQb1dpdHczR2N6QXZ3RkduMUwwRkl5bFo3eGI3TktxZlJGdjhN?= =?utf-8?B?SDdEQmVZMVBxMTIyazVRNG5adThuL2diOHpqTldkT0RjN2JJWXM2bGlVcm4v?= =?utf-8?B?YUdxdWhHZEgrMlRxRy9SYXZrV1JOL1Zsa0o0NzdsRmlJS1lvZVJHYXBjNFdU?= =?utf-8?B?MTRGQTF5MW8xN05ZYkV1OXdpNnZ3K2hZUHJ4V3EyTXBwMktCcEo1aEYvNVA0?= =?utf-8?B?L0dMa1Z2b3plRjdDQ2owUkEzRmdwYlU4Snh6TEVkQm9QWDExYWRiNlNac1pF?= =?utf-8?B?SnBqYjB6WlpQT0hoRUZiVUlUQTl5OHRxMnB0bnBQT1BLNDRKY0ZIRkNqMndO?= =?utf-8?B?N2tsRkdBNUxZSGFLSzhqZTk1U0QvWnpNK3JZaDRvQzhabzZlSEpDYnUyK1cr?= =?utf-8?B?S2xLa2IxWVdxOXdtVDdYd0M0WkFVcllUUDFTaUhhVWVHSTFtRmZEREkwRm5t?= =?utf-8?B?OGl4cHpOb3Q4TzM0bExCQzRsa2VwcmlTSGZuK0dNVk9pdzM5ZEdvQk5ZYUIr?= =?utf-8?B?Q21yOWh5dnY2SktybE84U2NDODNWNUJvMHFpQjBkZldhZENyVGh4R3BOSGRF?= =?utf-8?B?VGg5NVp0QnErb1FjWEFvYkJHaVZMaXg5YW1mT0Q3ak5RYTdGb1FrVm5kbURk?= =?utf-8?B?MzFRSXExYzFrcHVhOGducUE2RlNIZUFvTDFxdHNCTTVnc3d6WXBBMERkRjdK?= =?utf-8?B?U0w2akdDb3hXMnE3YnNxRTJBQkpyZ3ViMThHZloydFZLVjY3b0lBL2U1clQ3?= =?utf-8?B?RnM5OTNQTHp4N1Z1ZUk3eE1VU3hENDN6K05pSTdnc0NxeTF1VVo0emFYWld5?= =?utf-8?B?b01LcUtuMU5Oa3pSb3N1dzlkVWdjYVhFL3lNNjhJWUFiQTFpN3czNG1TMngz?= =?utf-8?B?T0pDNGFsU2JjbllNZ3pwRkJKclhIOWxMWlArcFJoUVAyQ0hCZ0dSRWdYejVa?= =?utf-8?B?T2hwcHE0MmZsR2tlVkJvdnNna2tyMk8vaGs1MUljOU1IN1p6VmR1RWNlSEtt?= =?utf-8?B?R3VVd3FQanpQeGxrZkpFOGQxd0k2YWRCTkNJemRJVldEaUJ4bVc0WjFYb0pw?= =?utf-8?B?SUhId1cvYWw1cU9MVDVaVWRmK043ay81Z0J0aTZSSFJPeUpBODRZZGFUd2Jw?= =?utf-8?B?SHZHdnZTQk14TCtYY3JNMnRNUlFOUkxnRDRuNFhBRW5GajNnWFFWSXN0SHRs?= =?utf-8?B?SGQrNWM3SzVBa2l5aGE5Qjl5c1gyYWFBM04xTk93eFltWk5OblJpMXprQWUr?= =?utf-8?B?OUhMQSsvaGhOZzBaWXJPVVJtRWt1M3FiTldyVjhLSUJyUHhUMmE5SHNoTHJ6?= =?utf-8?B?N0Y2L3RVTmhyKzNUOFMvWTBGRklmUUVYZ0Q3OEU5Qk1DeHk3UDVCTDAraDJz?= =?utf-8?Q?t9MM=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)(7416014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SGFRZC9HZjVFU05YK0wrKzVVUXVlMWlZS2dCWnNTT2o3T1AxQTUvZTdITlB4?= =?utf-8?B?clFYRUNJbDZVMDBzOWg2WEx6bXJ3d1QxREFSanZQT1VlbFoyaUo0TFNoMXp0?= =?utf-8?B?VzFGTDVRT1pCNlFHWHNFRFd1TlJ4czQrMzJUaWM0a1FBK1pLSFRicFAzUEFt?= =?utf-8?B?QlUwQVRYWWdwQmxxRFJnaFdCaTZlSFlnck91RDZqL3h0M2daV2R5YkxzSmY2?= =?utf-8?B?ODNLYTFtR1owUjhxYVAwVVlHQ1Z5ek1yb25wQ21aNDRxNnN5TmhuVnRsRkJK?= =?utf-8?B?VG5haWppZlg0TTlZQ2x4ZzFmL0NWeEc4TTR1ZnMxblhwczJ1SG9Zak5jK0VZ?= =?utf-8?B?enV3TGlHVVc0V01ucUczWEtPQnNjSGpYemZnK1NLZXpNR1pIWllRY0NIekpo?= =?utf-8?B?S3ZsbG8yTk9wa0cvVXZ1TWE5Y2UraGtPUzZWV0JUSWdEMW41ZFFLa3Y3VGsz?= =?utf-8?B?eXB0ZGI2MG5RQStWODlRSEZUT0tRejhuZUdqVnVCUzlXall5OWpNcjdaSjg5?= =?utf-8?B?VHRhME1NVlp6UDBVeTNaUy9ybEFSTUZZMTNvQ29xaU94UnVQTk5lUXhaZFEv?= =?utf-8?B?UEFOcHFGUnB6Z0cvUVd2Y3NZcFo2b3RKRU1RaVR2UVFBM1ptcEpRSlpia1Rl?= =?utf-8?B?SmpXQ2Y4YmFOb1FWVlprYkxQOFdwcDdvcm43T3hydlVod08zZmZoYVdva1o3?= =?utf-8?B?SVAxM3hxVURiYUUvQ01rN3lENHl1NDVhdnluQ2xHT3drMXNyZ1k3c1o2dUEr?= =?utf-8?B?L25Yc2xoSkhpSGFrd0htanpjaW8yNFN2czBkY2xmNEh1UFMvTDFOSXdjN1J1?= =?utf-8?B?L1dOd0tUV1hIckl2emtFbVhndnh3bXY5R2tzcGVZeFprSWNweFRYaVZIakxE?= =?utf-8?B?QW9pT3pZNFgwNTU1ckk4SXM3NG5sNWcwbnJNRk1rWmlLcVdFV2k3a1RFdkI0?= =?utf-8?B?cFpHYkRBaW5hYWtYalNZY08wUTJVRFIwRVhRY0wwZzA5L2FzNEJDYmpVNDJJ?= =?utf-8?B?ZDBtSDQ3S0Rqa2EzUEFZN0VEV3hTaDRKa3E4bmtIc3NGN3Y5elVpTmVlYTJq?= =?utf-8?B?MGxhR1BseVliU0tnNWlBNG5LNTVzTDlKZmtUVDdlUXR0a0tzQURSdlR1aHdx?= =?utf-8?B?bm5NeHRRemJQSXFrYldWYzJ3M21YZjNnWkZqUlN5MlRMVzVLVVJ5dGR6cGor?= =?utf-8?B?NFo1dG0xM1NDT3JvYmNpT3dVSFBmSHZOR0ZpeDNVbGZxQXpNaUp5bjkrWUY2?= =?utf-8?B?RnBJQVNzZUdoZkFUV01IRFZOQ2xQUGJ5azAzYnZrZUVteGNMTDNPSThEQzFX?= =?utf-8?B?NW1xdDkvYlY0TFJXZFRaOUVlTGVQazMyTFc5TkY5NlloSnBzczcxMExKcXpV?= =?utf-8?B?OWUvNHVUTWliYnhJT1g3Ui9jSW5pWk56aUJPdzVwOHBqUFpEM0Qvek5rSzRl?= =?utf-8?B?ajhUT3hSalQ4WjY1bFZmSDRzdjM2N3piU0FlM1diS3FFRkZRdlpreEt1aGph?= =?utf-8?B?bWtCL3A4VGQ2K1NNbFJlUW5CSzkvekVjYmVzOVNnWHFpWk5UWHNBT1Z2K1V3?= =?utf-8?B?NnpWNGlYNUpuVEhxNk5XL0dhREVFNDNpYjVlc1BwMFpaWkVBUkdFc2NNT1k4?= =?utf-8?B?MWZkUEJQS0k2L0Z2bEsvMitjbmZXaC9Tc1hnMk9uUzZNR3FROGx6QVNDVXJq?= =?utf-8?B?VzdyR05OdU5IL29YbU5sZ2VSci9oM1hYOHZ6Y21tME9EN1hkUlJXRXhBUjJm?= =?utf-8?B?T3RkOVFZc1pxUU54RVZvYmcycGozQ1BCK1M1N3VCUndOSGVvOGdZK01EaEc3?= =?utf-8?B?SW5FWmZ4ZzFycVFxV3dBRzZjcGNIK3M1dHQ5Z1VaZ0VRWjFzQ0dFNmFmcTBo?= =?utf-8?B?WldWWnZ0a3BVcm1LaFlsVnQxQ0Q4SEp6V0NlS2tyYTNOKzRMZUtUeWJXcTRZ?= =?utf-8?B?cmorZ1M3RzhxZk44NERVUVYwZ0tmTm5jSCtOZURDd2tRVEovUGI5ajZOcnVU?= =?utf-8?B?L0ZEQWRrNE01NUtyb3VzYlNLY2U2QXNEdUxTWVFVM1hOaVhNU2p6TzFPdTBD?= =?utf-8?B?WCtlY3NER2R0aWEyRHJEV0tqN2RaTm9wOGVNbzZhblNtVTI4UHdtUFJlR2JY?= =?utf-8?B?YXJ6NTd1RWtHSU10ekFRa2FSWGZ2Yk9qVXNaK1luT1J4ZWlEZTV6WjYvbW1T?= =?utf-8?B?K2ZML0cza3NlRitIODBFM2RLekRiSnpsczhyQVpDY2JRR0RWWmJLalBNUmhq?= =?utf-8?B?aWtaTS9BRTZVU0FnWWo0akdSWHQxemZkckZRSDlKVi9sSHlzS0luWkR4eU5U?= =?utf-8?B?dEZZUm8vQmd5Q3g0SEJDSGpFTW1kN3k5ODVFNUxqOS9RVzMyczlUQT09?= X-MS-Exchange-CrossTenant-Network-Message-Id: 51be0c0d-613d-49a0-e5e1-08de70f3be65 X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB6020.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Feb 2026 02:48:50.8685 (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: Pq8is6v6axN2nP2TrAWDEIowJR+AsLG5MXHgIwGFaWzUHF39bQpq29v2dfVP9cDkZsCoCRmC341E5GmiciOY9Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR11MB4907 X-OriginatorOrg: intel.com On 2/20/2026 11:25 AM, Qais Yousef wrote: > On 02/19/26 23:07, Chen, Yu C wrote: >> Hi Peter, Qais, >> >> On 2/19/2026 10:41 PM, Peter Zijlstra wrote: >>> On Thu, Feb 19, 2026 at 02:08:28PM +0000, Qais Yousef wrote: >>>> On 02/10/26 14:18, Tim Chen wrote: [ ... ] >> became much more stable, so we kept it as is. The wakeup path more or less >> aggregates the wakees(threads within the same process) within the LLC in the >> wakeup fast path, so we have not changed it for now. > > How expensive is it to use the new push lb, which unifies the decision with > wake up path, to detect these bad task placement and steer them back to the > right LLC? I think if we can construct the trigger right, we can simplify the > load balance to keep tagged tasks within the same LLC much easier. In my view > this bad task placement is just a new type of misfit where a task has strayed > from its group for whatever reason at wake up and it is not sleeping and waking > up again to be placed back with its clan - assuming the conditions has changed > to warrant the move - which the wake up path should handle anyway. > > FWIW, I have been experimenting to use push lb to keep regular LB off and rely > solely on it to manage the important corner cases (including overloaded one) > - and seeing *very* promising results. But the systems I work with are small > compared to yours. > > But essentially if we can construct the system to keep the wakeup path (via > regular sleep/wakeup cycle and push lb) maintain the system relatively balanced > and delay regular LB for when we need to do large intervention, we can simplify > the problem space significantly IMHO. If the LB had to kick in, then the delays > of not finding enough bandwidth to run are larger than the delays of not > sharing the hottest LLC. IOW, keep the regular LB as-is for true load balance > and handle the small exceptions via natural sleep/wakeup cycle or push lb. > Leveraging push-lb for cache-aware task placement is interesting, and we have considered it during LPC when Vincent and Prateek presented it. It could be an enhancement to the basic cache-aware scheduling, IMO. Tim has mentioned that in https://lore.kernel.org/all/4514b6aef56d0ae144ebd56df9211c6599744633.camel@linux.intel.com/ a bouncing issue needs to be resolved if task wakeup and push-lb are leveraged for cache-aware scheduling. They are very fast - so for cache-aware scheduling, it is possible that multiple invocations of select_idle_sibling() will find the same LLC suitable. Then multiple wakees are woken up on that LLC, causing over-aggregation. Later, when over-aggregation is detected, several tasks are migrated out of the LLC, which makes the LLC eligible again-and the pattern repeats back and forth. >> >> Let me copy the changelog from the previous patch version: >> >> " >> In previous versions, aggregation of tasks were done in the >> wake up path, without making load balancing paths aware of >> LLC (Last-Level-Cache) preference. This led to the following >> problems: >> >> 1) Aggregation of tasks during wake up led to load imbalance >> between LLCs >> 2) Load balancing tried to even out the load between LLCs >> 3) Wake up tasks aggregation happened at a faster rate and >> load balancing moved tasks in opposite directions, leading >> to continuous and excessive task migrations and regressions >> in benchmarks like schbench. > > Note this is an artefact of tagging all tasks belonging to the process as > co-dependent. So somehow this is a case of shooting one self in the foot > because processes with large number of tasks will create large imbalances and > will start to require special handling. I guess the question, were they really > that packed which means the steering logic needed to relax a little bit and say > hey, this is an overcommit I must spill to the other LLCs, or was it really > okay to pack them all in one LLC and LB was overzealous to kick in and needed > to be aware the new case is not really a problem that requires its > intervention? > >> >> In this version, load balancing is made cache-aware. The main >> idea of cache-aware load balancing consists of two parts: > > I think this might work under the conditions you care about. But will be hard > to generalize. But I might need to go and read more. > > Note I am mainly concerned because the wake up path can't stay based purely on > load forever and need to be able to do smarter decisions (latency being the > most important one in the horizon). And they all will hit this problem. I think > we need to find a good recipe for how to handle these problems in general. > I don't think we can extend the LB to be energy aware, latency aware, cache > aware etc without hitting a lot of hurdles. And it is too slow to react. > >> >> 1) Identify tasks that prefer to run on their hottest LLC and >> move them there. >> 2) Prevent generic load balancing from moving a task out of >> its hottest LLC. > > Isn't this 2nd part the fix to the wake up problem you faced? 1 should > naturally be happening at wake up. And for random long running strayed tasks, > I believe push lb is an easier way to manage them. This is doable and some logic needs to be added in wakeup/push lb to avoid the bouncing issue mentioned above. Consider both whether do it in task wakeup/push lb/generic lb, and the task tagging, I was thinking that creating threads within one process appears to be a special case of tagging. If the user chooses to create threads rather than forking new processes, is it a higher potential for data sharing among those threads? However, we agree that fine-grained tagging is necessary. How about this: if the user explicitly tags tasks into a single group, the kernel can perform aggressive task aggregation-for instance, in the wakeup/fair-push path - and let the user accept the corresponding risks. For the default model, generic load balancing can perform per-process task aggregation at a slower pace to reduce the risk of false decisions and over-aggregation. We intended to discuss this in a separate thread, though. Thanks, Chenyu