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 9ECF726299 for ; Thu, 18 Dec 2025 08:33:42 +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=1766046824; cv=fail; b=UnKsVyg4Hvi48ydiuVxitsR5mYbKgX3rEaqld6nVlOX0oI5IquIBtRoMHckjgylwk9MtC6MX2XhnlqtPzwAAvQRkz6GS6msPEuWlRljobe5/JZYpbX2rR/2gs02sUeBI2BK1IlKYb1vu48Nfn2Nd+i9aFo53npoTUakq35bUQLc= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766046824; c=relaxed/simple; bh=uj0AUvvn+QkpsD/axeQwV61k3ivcXRPwepDBMsuA3Rs=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=AD4ahV1nTwrX6BbxQ7WuZTUht4ZVAQ5bew+L68btHRsvEV47IXib3VjF3l5jTjKHW+yZMWZwZHM+Nto07wsL8ZvECcqFbTBaK2ym0VWj8xu8v7viOYUMwF0oT46CLHN9aD37RqwfIn8d/MfKWDL3FN/Tctf9vdRBlT5ippI9FZQ= 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=ed3T90Qx; 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="ed3T90Qx" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1766046822; x=1797582822; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=uj0AUvvn+QkpsD/axeQwV61k3ivcXRPwepDBMsuA3Rs=; b=ed3T90Qxg7EoGnhjrWWVAACM1p3INDeEAgajijI85A1WVapwtcHf7YdG auvjhCaOKcLtzYZA7OsSnguX4gYB87g0tOn6k60UuibIPwmwcOrNPSybt hMB0EXqlfcSAoTFklqIS2mXc32+evgjS0AyaII64lKupcvmGxKX5ZsF6u NoF/plOTF1H2o9JszhScBaj7KDPdnD+OqoaIq36v+fsJqj8pVniiI9BHa ymHRTh91C2wIhaJfJ4sS3/ssSozDw0R2fKTGD/iHdImFldnqKzF5USFi8 yRsP8S84ZvV5U+ZtheQ9yogrO0oduLzNy1Slt1xOHSkfeSVr3GdJQNhPz w==; X-CSE-ConnectionGUID: qkT6+d+zQS2yhr39PzykcA== X-CSE-MsgGUID: Ydr0h/5XTCyAz5as++rlbg== X-IronPort-AV: E=McAfee;i="6800,10657,11645"; a="90654015" X-IronPort-AV: E=Sophos;i="6.21,158,1763452800"; d="scan'208";a="90654015" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Dec 2025 00:33:40 -0800 X-CSE-ConnectionGUID: TsHBY5LnRsmimWF3DRzxRg== X-CSE-MsgGUID: IpK/qwkvS/mWn18KoEKp+A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,158,1763452800"; d="scan'208";a="197678835" Received: from fmsmsx903.amr.corp.intel.com ([10.18.126.92]) by orviesa006.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Dec 2025 00:33:37 -0800 Received: from FMSMSX901.amr.corp.intel.com (10.18.126.90) 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.29; Thu, 18 Dec 2025 00:33:36 -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; Thu, 18 Dec 2025 00:33:36 -0800 Received: from CY3PR05CU001.outbound.protection.outlook.com (40.93.201.44) 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; Thu, 18 Dec 2025 00:33:23 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=vgVetl6KBtsdeb6q263R06H9yvgeMnCzG8xGeK1YikwGrFnn1e9ZrvXVJ56gOTt9/wKSUp/yczYDYsh+RgBNif4qIkP/gA2+v9PcVWq+VEfU1fM7J4fJjUkJ24AoG6ziLfv2XscSNuPcreQ2RPSMv3vTsiaw8b9arLdFWuTcxiQIoQWtF40wjbsvIEl+fOCSdA6PwJ8WjGMaUcHCd2X0D76DZeE341VmtFhRdNT3A7Ezy48EMoYxhCisup/RLA0191LlFocaVCpSyi45j0OctBLHFuqVjJej3EdajP6CS2Ltj4OBkbULH6tH2PZXf1wcUuwc0HuY2OMImF6ciQ6PMA== 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=i8m17N3+CkJvub3aIekTbkprbChBiWBe3XenLRZhFV8=; b=nPUyqf2a7pC1hdb1gZUGIn95TjJQpA0Oy5zKdHmX1tWvu//Bxl7mUyIJk1+pM3xKMN6VwA+AQJFos9juu6vg4FEchiQD95P1Zlz9PnadTgtMp/fxWzTYnDUEnmXEGbev5WNYGCkLiTnF4kEko9NXHkh5kWgrvRlP7ti2HEIrl9MrUpOSdjEfssje1EaVQEnTkaPWZpVErL2zjsun3Y6naDbklejvBAi44D7vEq3BzbfJicg+nCtQXZ7mNm1+GD8Ea5DBKD+yYzYi1Bv3mkj13UxEdjFDeLNB+81V4oD4A+e4oY6/9ylwA3vY6/JuERXK+ENZuJLIUTZC49KlfciVUA== 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 PH0PR11MB7586.namprd11.prod.outlook.com (2603:10b6:510:26e::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9434.8; Thu, 18 Dec 2025 08:33:16 +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.9434.001; Thu, 18 Dec 2025 08:33:16 +0000 Message-ID: <61cc2b92-1b5a-4af5-9d88-96097c3b0619@intel.com> Date: Thu, 18 Dec 2025 16:32:52 +0800 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 19/23] sched/cache: Avoid cache-aware scheduling for memory-heavy processes To: Vern Hao 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 , Len Brown , Aubrey Li , Zhao Liu , Chen Yu , Adam Li , Aaron Lu , Tim Chen , , Tim Chen , Peter Zijlstra , "K Prateek Nayak" , Vincent Guittot , "Gautham R . Shenoy" , Ingo Molnar References: <91a7c325-5093-4417-aa98-34df694b0c39@gmail.com> Content-Language: en-US From: "Chen, Yu C" In-Reply-To: <91a7c325-5093-4417-aa98-34df694b0c39@gmail.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: KU0P306CA0063.MYSP306.PROD.OUTLOOK.COM (2603:1096:d10:23::11) To MN0PR11MB6009.namprd11.prod.outlook.com (2603:10b6:208:370::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_|PH0PR11MB7586:EE_ X-MS-Office365-Filtering-Correlation-Id: 663a7a42-566a-472f-684d-08de3e1016b1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|1800799024|366016; X-Microsoft-Antispam-Message-Info: =?utf-8?B?emIrNmRzcitkTDNDQzhrdS9MM0hvRG1DMms2N1B6SXpzRURwYVJrcWdJZkUz?= =?utf-8?B?QkRwVnUyUEVidGRKVVlSOXFHMFl5ZnI4MUxFVzhJM3ZKOXM2OHNBeVlITVJ6?= =?utf-8?B?ZEViRXNnc3ZuVEZqQVBXa2FkVURxVG9zbHdOV2p3emZsQXVRZnZkNjBHQzQy?= =?utf-8?B?OFNkVGpFUVhEYk5IRVJ3MXlBeGxGcStiNmZnMnpQWW1lZFkxSUoxd0EvMTFw?= =?utf-8?B?VmY4N3BSNkxxTCtIV25CNlYzZVZ4ZDUwSWY5SnlYUzRHRFpzUzlCUGw5UDhP?= =?utf-8?B?VHEydnhuYWFOT01hdGNOaWVtdWI4TytGWi9mdzZGOUZJZUVSVnNGV3Vqd09V?= =?utf-8?B?L0dHOE1sTVZuTFpSQjNGOTFzTVVqMnN3ZGdPdDl3RWIzS2FtT2NPMG11V0Mz?= =?utf-8?B?ZEY5L3laQ1hoSWxOU1hlVm9peTRNV3hNMDBXYzFESzRRdHI4L2xUSWp0dWNv?= =?utf-8?B?VEUraDUvZVdUVWo0WnFGQmRUd0lNK3hkeUpvdGtLU1cycm9UTGwyWkN0UVNG?= =?utf-8?B?SVdwUDJQRXBEdUNKSlg2SDI0S1B1ZEN3QkNReG5pTDYyZnhJcndWNFRXMk9t?= =?utf-8?B?S1ROdUVPb2hEZU94QS9MbDFMMllES3ZjRHdTSzZEUjk5Q01jTGxWWlBLczQ0?= =?utf-8?B?dmJac1ZLWDAyMjNnbWg2dmkrOGpyZTlGeWlaR0ZHR21oMlhxaG5rd2l3enk3?= =?utf-8?B?Wi9BdW4rS3UweGo1TXhkRy9tY1paNStRVDVGV0NvZG82MzFhSmloWG5jL29k?= =?utf-8?B?U0ZvVlAvSnVwQ3d0YnNsNGJFTXErQ0VZZkZ6WDZpLzdOWDFGSWdBeDRXM2wx?= =?utf-8?B?eUFwU2p2aE1vSlRxZCtsYmltM3RqWnVuYzRDdTBxV1FLbzlEL0htV04rT0Fq?= =?utf-8?B?WFl1SDNmeEkvb1VvR24rV0Z6RTl1TllrTXQyaURHL0orTWZZOHdkOGNCZjQw?= =?utf-8?B?eEZJc2J2bytuSFJtcGVIcGRsN2xJUFQ1MlZJZVFWRUlySE5pb2Z4NW1vZXlw?= =?utf-8?B?TWNEcit6NjdJekJLZ21UYXlUNlZOYVNBak5vN0srRWFPS1BqS1RWRGovektB?= =?utf-8?B?bTZBVVd6UzFkanJ0R29KUWluZnRGVDF5c3hvS0c0ZDNNZ3ZaV2JXeVR5czRk?= =?utf-8?B?YmNnT0lNMXA5WkVXZUpMQXN5S0pYd3hIMElua2p0VEFIRFBxU28xVy9pekQ5?= =?utf-8?B?S0Z0ZW5Sa3BaSndnOXpkTzIzZ0M1QUIzSHBvd3FpdWcyOXhuUVNuSGRmTmRV?= =?utf-8?B?T2pBVmYrWFRMSDFWNzRMU3NDcXBOWU43dk44Zi8vRWd4c2s5dTB4QWEzdVB5?= =?utf-8?B?WGxsbDRBZEhYVnk5UlUweWc0RnJDaGhtMjc1dUphdjUyaGtqK2FoaXF5YXVi?= =?utf-8?B?MmFxMElua1pia21ZNlJjVzUxR2hhUU9yYWZxN05KeTZMM05OaW9EdGc3ZHg2?= =?utf-8?B?NjNoTjIydDdWVGoveStVYStvcUZBbjY0TUlHc0RzM0czN1hxeExPLzZrbFVN?= =?utf-8?B?WFIyL0g3REo1VHkrckFSWkk5TnhmM2JsVUtFa1UwZHJSYnY2cXkwb2pVV2R1?= =?utf-8?B?aHBncGpSc2pTaXluUHpDN2ZuQ2xtSGpDK1kvQlp6L0s4WmVJUzRGdlhkRHpz?= =?utf-8?B?MlBuTVl6UWVsVnhSSXFFR1l3dWpsZTVFR2oyUHdkbGNBOHpneGw2Z1VCL1Jp?= =?utf-8?B?WG9wa0M2a2QzNE5vVWFldlB1WlNsckpmR0drMVRhZGlvYm5mZmtKQUYvUXdC?= =?utf-8?B?Yk1KUmlSNjBpSGVGalhxQ2NRdXVmT1hYRWl4ZEhBb1JaNHRlaXF0bG44TjF5?= =?utf-8?B?RlJYdHdyaHYzRjFMd2VsdWo1dVd3RVF3cTJIRGwvOVJBc2QvSVRXcU9KY0p5?= =?utf-8?B?YXlHQ2pKODh0V2lSWXVOSTRVcnlMalBVcVdOcXkwak9FN3ZwNjR6SXVpOHFa?= =?utf-8?B?dHRyOWk2d3RzZWJUSmY3andZeDRxaEVnTmJ4dkE3VXM3L0RIOVZvRHFhbXF3?= =?utf-8?B?MjJpM1J0cjN3PT0=?= 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)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?d0FCaEErYUFQdW1LZWFpM2hvditjRHU2cndyN1F2d2xENUxteWVIVkFJN0NN?= =?utf-8?B?UmtZZFpyWXA4QzVTRHF1TFgwdklKQUZLeklES2RSVUdqVnlrRGRWTkgvZkww?= =?utf-8?B?RFVYUXFYTHVJbGdabCtXNW9kbmtGN2toeGVzcUwzdjBXZ1hWb1pjWTlyYW9G?= =?utf-8?B?Q0o1U3hWdEZNdTJ3ZG12SWJtN2kyaFpxdjNmdUpBcXRoZE5lWVpNbGlIUi92?= =?utf-8?B?ZjY0d3QzbUlta0FsRnp5Q1VsSG5nSDNWQlNSYUF2UUgrR0V6V0ltMjUyTUpt?= =?utf-8?B?WXhqVkFES09xUFRqTFlLTzdpcUZxUFB6bWRtdkp2UGZ4V29WTi93WWx5Tjl1?= =?utf-8?B?NVV1NXVldzVKVEFsNWg2dmxiSmw4Yk5aY1pWRUNqTDlwQnRaQlFaWEJLOWJL?= =?utf-8?B?cFIzVExZOTF4T0hPUTA2NkxJMUkvZ3diSTI1M0JkdURGblNjNndnWGgyQXpM?= =?utf-8?B?ZVkwQVU3SkR5M3NDcnV4V2dIWWJJZDQ0dW4vRDBGcW1vMW1CaDYxS3oyUDBD?= =?utf-8?B?N2RsTDJCUGdxK011WHNkeUJkWjVYaWpSQU50SzdxY2NOMHJDZld2aktMTUVq?= =?utf-8?B?N0g4N3ptb3FoNHJ6MDdsT3hNNHhPUURsVUFoa3hrWVZ6eTJDUVZVdEpQWngv?= =?utf-8?B?Lzg0Z3RKN3Z2cjVFQzRnMFF1MzBlamFBdGdhZVJ2ZTBxTVJRRi96TnJnNTAz?= =?utf-8?B?cHN5TTVsNjFTTGdBcmd1UjQxc1dBL0JkYVJ3djhHbmxzeEpETXhjUjd4Qm9Z?= =?utf-8?B?YVhGVEtJVHJuUTNXODlIY0JreXJYdmVFS2t0c0VCT1BXMkcvSXdBQzdCUEpw?= =?utf-8?B?NU1HWGNPVFp3SVRUaHZmdGplWUJwYjRpUVNxQVM1ZFBzOU1rRmVFRkxCVkFF?= =?utf-8?B?S0dCOW44NWdVaW5pTzMyYjhyeW8wVFlMclBiMmxpTk9TUTNObnBxVVdyUWpF?= =?utf-8?B?YkdTdy85eWkrRm8za1hiMkttVWxvS20zQXlkREtmZithQSttZ2ROUy85WFlY?= =?utf-8?B?Tk9pZU1lQktwVmQzMVZnOUFZYkxoQXc4Mzg2WExvY0VtK2h1TmF1SlhkSk15?= =?utf-8?B?VlgzTE83R0oxcTlWalgwUlhGN01wdGlqTENCWC9WZFZkcjBwajYxeTNjNVcw?= =?utf-8?B?N3U5dkRNVCs1cFV5bG5qVGFDZWQwNm1HTGRFWFFNREZVMVZPWVlFd0lIQ29y?= =?utf-8?B?b0NEZE0rSXUyTTdxb2RqZHZyRGhRMVlwL25vOEwzRGVwcE9BWVYrR09sSzJW?= =?utf-8?B?NDR2S295YVRseGJyNUlkRFVHL2h6WThPMzNVWVhrTEtWV010Mis4RWcxRzc4?= =?utf-8?B?Rk95ekI4TnRLMXArb1ovZDhlNkpid0pxRklQbXQrRWlrcVZSWk5yMk1SUUUr?= =?utf-8?B?aEFLeUpEOWJIRW1FdnVNelhFZE9wa2owSks3Y2ZLaEptQUdEeFpOMWRzSU5l?= =?utf-8?B?QmJWY2NpRlk2RUhoYTdoUUhhTmVMTThLSGtxeWxGMFJiM09zNFRjdnZWUkZm?= =?utf-8?B?SUtrM0Y2UDg5d1RLU2lRbi9CL2dKL1BIQzlrWEZWVDIzcXpiNGtBcUxoalQz?= =?utf-8?B?N3NDQ2pQcXB4WVZpTGUwYkZkbVlBUTg2Z3RvRUlvOU1nMXBKQzY2akQ4M0xW?= =?utf-8?B?aVp2ZUw2MG9naU1BVWU0bE5xSGxkaU9PZjBxRHZRZnhJOENldlQyUmRiSkFO?= =?utf-8?B?ajN1MjRSZk1pakNOR2phUkF2OUkrVTNmVGZVdzlwUmdRMWdHUVJpN20xQXph?= =?utf-8?B?TTNmNTZrNS94UldnUWJxT3prS2JFWE8wQmtxTWVYcDEyU0ZRUnZCL1JweXZC?= =?utf-8?B?QUNEMzlKSzBZa1NoMi8vTlZ4UUk4dmZRM2UvRkZWUk9kRGNGSzJSYXB0R2Zn?= =?utf-8?B?bCtIdlpOUG5JcjF2ZkdSQ0VuekRmTmFCUTMzQTJkZzcxWE1QeE80QkluUU5n?= =?utf-8?B?c1NkMmNwNHJzRTRyWFBub08rS2JuTktrTmRyRHZTQkRtbWFPNFhmTkpISi92?= =?utf-8?B?ZEZrSW9iMlBNVFBDNzk2MEJpZDYwWmZqWm9tT3U5QXRVbUhTVnBKeGJJTUN3?= =?utf-8?B?QzlVWUxuUzlTNUZZUjhBMVJ6MzBNdC9PMW1NRFAwc0QyUm51NjlRdGFiekFz?= =?utf-8?Q?KjXsv5yVAa00avXervAJl92uW?= X-MS-Exchange-CrossTenant-Network-Message-Id: 663a7a42-566a-472f-684d-08de3e1016b1 X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6009.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2025 08:33:16.2518 (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: nfjjsVQ8V4tywrUqymcxThFOWrxxFULSdGpwlHgGWSp8+NIh8jSCNOZwZF6xQzwTzKCSnS1uBHWzTaXoRSbRhA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB7586 X-OriginatorOrg: intel.com On 12/18/2025 11:59 AM, Vern Hao wrote: > > On 2025/12/4 07:07, Tim Chen wrote: >> From: Chen Yu >> >> Prateek and Tingyin reported that memory-intensive workloads (such as >> stream) can saturate memory bandwidth and caches on the preferred LLC >> when sched_cache aggregates too many threads. >> >> To mitigate this, estimate a process's memory footprint by comparing >> its RSS (anonymous and shared pages) to the size of the LLC. If RSS >> exceeds the LLC size, skip cache-aware scheduling. > Restricting RSS prevents many applications from benefiting from this > optimization. I believe this restriction should be lifted. > For memory- > intensive workloads, the optimization may simply yield no gains, but it > certainly shouldn't make performance worse. We need to further refine > this logic. Memory-intensive workloads may trigger performance regressions when memory bandwidth(from L3 cache to memory controller) is saturated due to task aggregation on single LLC. We have seen this issue in stream benchmark runs in previous version. Patch 23 introduces a debugfs knob llc_aggr_tolerance that lets userspace tune the scale factor. This allows memory-intensive workloads to perform task aggregation when their footprint is small and the administrator considers it safe. As you noted in another patch, fine-grained control would improve flexibility—and this can be addressed in future iterations. >> Note that RSS is only an approximation of the memory footprint. >> By default, the comparison is strict, but a later patch will allow >> users to provide a hint to adjust this threshold. >> >> According to the test from Adam, some systems do not have shared L3 >> but with shared L2 as clusters. In this case, the L2 becomes the LLC[1]. >> >> Link[1]: https://lore.kernel.org/all/3cb6ebc7-a2fd-42b3-8739- >> b00e28a09cb6@os.amperecomputing.com/ >> >> Co-developed-by: Tim Chen >> Signed-off-by: Chen Yu >> Signed-off-by: Tim Chen >> --- >> >> Notes: >>      v1->v2: Assigned curr_cpu in task_cache_work() before checking >>              exceed_llc_capacity(mm, curr_cpu) to avoid out-of-bound >>              access.(lkp/0day) >> >>   include/linux/cacheinfo.h | 21 ++++++++++------- >>   kernel/sched/fair.c       | 49 +++++++++++++++++++++++++++++++++++---- >>   2 files changed, 57 insertions(+), 13 deletions(-) >> >> diff --git a/include/linux/cacheinfo.h b/include/linux/cacheinfo.h >> index c8f4f0a0b874..82d0d59ca0e1 100644 >> --- a/include/linux/cacheinfo.h >> +++ b/include/linux/cacheinfo.h >> @@ -113,18 +113,11 @@ int acpi_get_cache_info(unsigned int cpu, >>   const struct attribute_group *cache_get_priv_group(struct cacheinfo >> *this_leaf); >> -/* >> - * Get the cacheinfo structure for the cache associated with @cpu at >> - * level @level. >> - * cpuhp lock must be held. >> - */ >> -static inline struct cacheinfo *get_cpu_cacheinfo_level(int cpu, int >> level) >> +static inline struct cacheinfo *_get_cpu_cacheinfo_level(int cpu, int >> level) >>   { >>       struct cpu_cacheinfo *ci = get_cpu_cacheinfo(cpu); >>       int i; >> -    lockdep_assert_cpus_held(); >> - >>       for (i = 0; i < ci->num_leaves; i++) { >>           if (ci->info_list[i].level == level) { >>               if (ci->info_list[i].attributes & CACHE_ID) >> @@ -136,6 +129,18 @@ static inline struct cacheinfo >> *get_cpu_cacheinfo_level(int cpu, int level) >>       return NULL; >>   } >> +/* >> + * Get the cacheinfo structure for the cache associated with @cpu at >> + * level @level. >> + * cpuhp lock must be held. >> + */ >> +static inline struct cacheinfo *get_cpu_cacheinfo_level(int cpu, int >> level) >> +{ >> +    lockdep_assert_cpus_held(); >> + >> +    return _get_cpu_cacheinfo_level(cpu, level); >> +} >> + >>   /* >>    * Get the id of the cache associated with @cpu at level @level. >>    * cpuhp lock must be held. >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >> index 6afa3f9a4e9b..424ec601cfdf 100644 >> --- a/kernel/sched/fair.c >> +++ b/kernel/sched/fair.c >> @@ -1223,6 +1223,38 @@ static int llc_id(int cpu) >>       return llc; >>   } >> +static bool exceed_llc_capacity(struct mm_struct *mm, int cpu) >> +{ >> +    struct cacheinfo *ci; >> +    unsigned long rss; >> +    unsigned int llc; >> + >> +    /* >> +     * get_cpu_cacheinfo_level() can not be used >> +     * because it requires the cpu_hotplug_lock >> +     * to be held. Use _get_cpu_cacheinfo_level() >> +     * directly because the 'cpu' can not be >> +     * offlined at the moment. >> +     */ >> +    ci = _get_cpu_cacheinfo_level(cpu, 3); >> +    if (!ci) { >> +        /* >> +         * On system without L3 but with shared L2, >> +         * L2 becomes the LLC. >> +         */ >> +        ci = _get_cpu_cacheinfo_level(cpu, 2); >> +        if (!ci) >> +            return true; >> +    } > Is there must call it one by one for get llc size? a static variable > instead in building sched domain? I suppose you suggested introducing a per-CPU variable, like percpu(sd_llc_bytes, cpu), or something similar to struct cpuinfo_x86.x86_cache_size. I am not sure if the community would endorse introducing this variable, given that sched_cache would be its only user. We can leave this as an open question. thanks, Chenyu