From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from DM1PR04CU001.outbound.protection.outlook.com (mail-centralusazon11020102.outbound.protection.outlook.com [52.101.61.102]) (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 DEA3C450FE for ; Tue, 18 Nov 2025 01:27:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.61.102 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763429258; cv=fail; b=jY+ij+v9FCX9XhPnUTr28Y4Oq+apKUc4iSumuH1WNxpFWFMcsZPAPWY3tHGprGRF2f2kZALIVIf6s17V+MOLkaENTXZiwNbLfYcmbap0dzb8zYPMjH7g9qjHIkGPrxSBABs8Gqg9VCyrautIHg2uRVgv6HJpYvUC/jEPy8Khdrg= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763429258; c=relaxed/simple; bh=LZ913J7ajeFJrPamMhK4ik6JA4kgvXN5pJqBWk5II9M=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=fDWUbY1Lwoy3+hHXb9994DR4kmHLoSP2HwvyefTWHHyWIocqAHkdZOjlAgQ3Wz58S+mAR6sQGiYvH5blAti4FaBX6k1zHqHpKadDIaF7FLYKDdkd/SSMVzFEuf98sh3oLmvH8qye1qiThSOReU54ODgc0qJbMyObyPc3Ggpjp/E= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=os.amperecomputing.com; spf=pass smtp.mailfrom=os.amperecomputing.com; dkim=pass (1024-bit key) header.d=os.amperecomputing.com header.i=@os.amperecomputing.com header.b=vsWh+1jQ; arc=fail smtp.client-ip=52.101.61.102 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=os.amperecomputing.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=os.amperecomputing.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=os.amperecomputing.com header.i=@os.amperecomputing.com header.b="vsWh+1jQ" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=uu1JPhdjB5WgSYpNLbbFWjib6Pa6w6S5gsD26DkXPrNVs3oXeL4Cb2A48Gln7wadQVqO86pXZqaIT6VvxEKkPOxJz29qo3LDY4wzVKrM4OBMW6m2/hcBS0Fh6I9wk5ZCHiCCMDGetauzQXpp4VysVTulkcu/EqSgmas17AZ+oB2fXuRobiclZB/nqY1tjnrv1mVpxOYJ1UItDe4zFTInOiGfvotI3PdzdjyLQQbMQvX41IZKNGJzDNjQ5vN0faS4OZ96T0o01tc+4ukjqcy/Za56KewGNKdh9Whutm+w04edsA7Vu8XC1mStu2LdvMRqCl9Y0b86FVNyfEPpdEtalQ== 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=PdeSbYZnLGoYQm12mkCBcAZ6x0diZi+hNkZXkHjFGG4=; b=e6FjGt/s7or/vVr4fYfKGJZbRSkUzd4N+AZ29Z+FvzWN50vCouoQRinxLhjsjujsJIeyNl9GVQDFOe0BhG84ZywtosuEoeS9ejq1DhrpVVnujOeP7fpi1VG3lui0cRIfzenw3stLv2DialNsMvCCf4h1Is6ylsgKtKUuRGZtaxeAwDM1bXFOtuGPYzHJ2K2Ad7gb92Dbapja6Me0M/C7GGO5Qew5733pSwIxmmAWJnOjLCzn3kntyN6KXZrFK4K/BxjfRI1Z7G9SFdlk8lL20sgFk7oDBYBEcM+r7RAJvV9tdt0JeePTReGtTmlRVnaASK4wFA1yN2Z3z4Zn3UrOBg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=os.amperecomputing.com; dmarc=pass action=none header.from=os.amperecomputing.com; dkim=pass header.d=os.amperecomputing.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=os.amperecomputing.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PdeSbYZnLGoYQm12mkCBcAZ6x0diZi+hNkZXkHjFGG4=; b=vsWh+1jQS0JvwWlC23H8Jvz9j8FfFv3/zg0nBAOzQFY1Z9w57uPA9azSZK3r0GaP0HjP5JBfuk/OoAVYbHFka66F3d11SMPO+AdMWB6HNJr3QgEdZO9WMDV/FSwbFIV1I9Iv5B6NUHKwpysSUd3u/QMtRXHHqiizHGghWbQpvf0= Received: from DM2PR01MB9464.prod.exchangelabs.com (2603:10b6:8:2e4::17) by BY3PR01MB6514.prod.exchangelabs.com (2603:10b6:a03:364::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9320.21; Tue, 18 Nov 2025 01:27:31 +0000 Received: from DM2PR01MB9464.prod.exchangelabs.com ([fe80::266a:4e36:5d46:1322]) by DM2PR01MB9464.prod.exchangelabs.com ([fe80::266a:4e36:5d46:1322%7]) with mapi id 15.20.9320.013; Tue, 18 Nov 2025 01:27:31 +0000 From: Shubhang Kaushik OS To: Vincent Guittot CC: Ingo Molnar , Peter Zijlstra , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Shubhang Kaushik , Shijie Huang , Frank Wang , Christopher Lameter , Adam Li , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v2] sched/fair: Prefer cache locality for EAS wakeup Thread-Topic: [PATCH v2] sched/fair: Prefer cache locality for EAS wakeup Thread-Index: AQHcSdIkzb5ACY/RjUKE3gUR7pL817TgrgAAgA8jSUGAAnJjgIAFbXA5 Date: Tue, 18 Nov 2025 01:27:31 +0000 Message-ID: References: <20251030-b4-follow-up-v2-1-19a23c83b837@os.amperecomputing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_5b82cb1d-c2e0-4643-920a-bbe7b2d7cc47_Enabled=True;MSIP_Label_5b82cb1d-c2e0-4643-920a-bbe7b2d7cc47_SiteId=3bc2b170-fd94-476d-b0ce-4229bdc904a7;MSIP_Label_5b82cb1d-c2e0-4643-920a-bbe7b2d7cc47_SetDate=2025-11-18T01:27:30.271Z;MSIP_Label_5b82cb1d-c2e0-4643-920a-bbe7b2d7cc47_Name=Confidential;MSIP_Label_5b82cb1d-c2e0-4643-920a-bbe7b2d7cc47_ContentBits=1;MSIP_Label_5b82cb1d-c2e0-4643-920a-bbe7b2d7cc47_Method=Standard; authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=os.amperecomputing.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DM2PR01MB9464:EE_|BY3PR01MB6514:EE_ x-ms-office365-filtering-correlation-id: fabf0683-1e3e-491a-df4d-08de2641a514 x-ms-exchange-atpmessageproperties: SA x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|7416014|376014|1800799024|366016|38070700021; x-microsoft-antispam-message-info: =?us-ascii?Q?g0mdzxxxWM+XCQ7R6V2Fo4pL+PlfZ80J102f/Gb3Sp7ZK61hAyqjHCBD2fgO?= =?us-ascii?Q?SrjePq+5WhcXvlgSPPlE0ldvupF5UQmL6rGz+Aw9PfPUcz1Lu6yBNYdqJHJu?= =?us-ascii?Q?giOU14lWvmlqenA58jNx1S1mQdp+afEc3T87rWd3LPtY4JLiV6n0DMQQVEmo?= =?us-ascii?Q?yeTn5S1Y38od0MIGBdT8YcDlZP7j487oN8162QgpeO0C71lfoeQFjRN1ixt2?= =?us-ascii?Q?gADOV4SblQASBthLkE8ZQWsB8xVBj7xSTM/HXxWDaJLM795K3ZTx+GTrQhzX?= =?us-ascii?Q?eV1npVBL2D623aO4zWZ3QTvSHV9AyX0IuQ9anexO8wiQjHKHhxX0DFOQRhnP?= =?us-ascii?Q?d7xLSfa4JFnlOThDwsPrI3v6b6HE4+5Pw4dMcnMxyGYw9dfgGBX8/bkLEdqE?= =?us-ascii?Q?065Y1KiTgn935QKld8yIcsTS/6NXuS4liqi9U2RNzEHL5GJyFKiTjOgr1cjl?= =?us-ascii?Q?AgMkX6SHIf1UrxbJr9QFmWJmIOmhX01qno5iirqKcp/CESC2JpjQj5OvaKOX?= =?us-ascii?Q?oXcy6XSI4vzLr9q40xOfQlP6IfAl71HDhhCJBZToQldZXxtgmCi9VtIYDomH?= =?us-ascii?Q?JBfHUaSiulWlzVE+4A5+yiRhA4KR0WEl1eGvqui5I9kt5s1QDGjgbhgj0QoH?= =?us-ascii?Q?9h7fACr1j1Hu8+j83Hy8UD1m54AkuqBrQM8dkOXWowXh1b9AI9AQuFsXUxkk?= =?us-ascii?Q?PWryWVqdlPUZWX+T6RdBtFIVlDcqiQZICh9MKVXjr7UDGgOj8gajov6NJl7K?= =?us-ascii?Q?5CbbhPeljBkhRHLdym06tAtfgxdQhqdXVS1FenMiW49/fOXFvANZpJUPohBJ?= =?us-ascii?Q?9IQ7LbYR8b7FxNm2uyKUznP84Z6SeWsh2be6cA7wLZsHxE4xtBgZfDTcmfK6?= =?us-ascii?Q?8guOIq62mn5EatKbLhiHuneqvNBwQ2UITDqqf8X7dNii5PUT7e4qJDvLbgnc?= =?us-ascii?Q?v34+FAmdmr/a2iCCCOd0RUuk4MCoE/do0Uel4+TW6F59jCLJKE8qpn9Tda6O?= =?us-ascii?Q?ae9O6Te47Uxc2MqZU2WIM+arCr+u1bJ+f6E874UHK5swy1+3zCXCJAliSP5w?= =?us-ascii?Q?0W3slo1tsMFyzqe6M3GmFyPatNNz8/R6ebKbZ58I+762fxF1NB3bPtHJV5V+?= =?us-ascii?Q?UEpkXnk7E6IvBS0E97aMWXnNggEPBE3aizSHFVupxoaX/haRLF0sxPJq1yeu?= =?us-ascii?Q?0XvciGIhIAYvBWepUNgkcC6dCd4DY9yxHKJATawKua6kcjRzMqVe9lqaJcsz?= =?us-ascii?Q?BYGFppt3dAyfcNt/hBTVBV8Iw+AMPh9b9l55QRZDp/42j81W041UT+2sXWBq?= =?us-ascii?Q?rI+HW5R3EpS2L0sc4tA4IzwIZ1mMgCTKCaK64Y2pizJn11/j6CqiNe8wTVG3?= =?us-ascii?Q?cgogf2KvEw/BeKbOWMXNJJ9BUXPqKJZJvTuA/LYz3tZxLxmWyIQ+0aOZTxz0?= =?us-ascii?Q?6/Rpee22dTbx12LzV61J7ybWXxWJrKus2U+WC6QvamXtFdk9xmJ1Tj12qG7o?= =?us-ascii?Q?bnmjF6FSzplE2etX4jCxr6vPqUvqPcX2Zs0+?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM2PR01MB9464.prod.exchangelabs.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(1800799024)(366016)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?zK7bkq2dsX5U/TPUr8UDstcJljpM7CibQP2fjgT32nhd9BtC7UJ0lP+3QN5M?= =?us-ascii?Q?gX0A4sJIP5Y23eAHG+Fz3bUzTvo39a1wl7Vlt5gV8eV4z1fR9ijHepLHhTrG?= =?us-ascii?Q?jomN/Z1MUdxZhYN8ejjseqqpF7FVWevO3kVNywsj2xxDnBtE0mssBfTp1CTj?= =?us-ascii?Q?QBOJ8hlgrgrPlpeRXA293TBipnaidiuvWFUl8g5hBGqc4GSKsJUdOY3jU0ws?= =?us-ascii?Q?svKd+dWckyxpIE9DKiE0CR2kF1c3gH5KK3AsNw+QFtTC2Fe6MPmnJiMGYpnh?= =?us-ascii?Q?7zQUeLzymdF5KE3CQoKOV1HY2wKde3Or+EMSslbHeCBSxbsIzEys2l8e4S8X?= =?us-ascii?Q?+OiEue6DC+Tgg/YkpT9uJLfSIX0ABJT4PeYhnsoY2EsP55Ov4UyrIOh9kCBG?= =?us-ascii?Q?+G6zFSDhuAiJJlUcnC8Qavx93uiVMQaOwDbFDwKEM2/UA9vP3m12UHhYCw3Q?= =?us-ascii?Q?/17DbwyKANfhH/cH1i1BZhQS7CPMcpde64Sk2j/0NMPbpNpNC1J0efbeEDsm?= =?us-ascii?Q?13jXf1IuJB0VDRS9du0iBdvU2+1JNJ6bYS4D1X0buO29H2duYJQPwV8i45NV?= =?us-ascii?Q?V3K/gBGPBcgNxy7J0EHMwPUMHTTMpC+LycU/YM156bAa4NFHcQ/1tefON6Ia?= =?us-ascii?Q?5Ctlg6+ptfB1VyWFUjPQLAU9thRART8UpWtX+MFrmKwVk7oVAgy3X82uXgL1?= =?us-ascii?Q?LvjSHfpIulkzD4GYUT80OMrYsul/YQ452agQfM6IzHZS3hASpImEgI3DAOLk?= =?us-ascii?Q?Uo504RUYT0IagQsDrmz0vi2qI4L8x2SVjAkWQWR0m1K3Q6okBPkb793YHcdz?= =?us-ascii?Q?FdCoKS818y8YgxNI2u87BiipaVbUTxdGeA6fL17k1HfcmzaoMlmk8F7ufA9j?= =?us-ascii?Q?fDY50l636sTYvNrheJ9zFl7PJKa2bSBi5p1weuYjw9PwKFxYivtzeRaup9Na?= =?us-ascii?Q?+pYU2p+KcmbMug9nq166Nby9OZb7wkO/MXa/6wghw9LRRFROOHnAMBxv5Gm9?= =?us-ascii?Q?OuMYCU2alCsZ1wo+igku1qa35jMtuPBYHin9Zjz+8jmeewGniiCdvKxD9jl3?= =?us-ascii?Q?XZl9AtbfygbuIA8nWP+XlKs5Fc8tVGFnbCpz37JnqZJhQVNnPBnw/v3NyNsh?= =?us-ascii?Q?9KqPmRNfyMoWfoAArFg3s5R2Vg7Rlt9lZb89V3pY66hDkDzXAw0pDW5vz0pt?= =?us-ascii?Q?XzeJAwIsafdDbrUUyj07a6+27T9Btm8vB90pVB2FThGhB6SwRdTSd6KelfKq?= =?us-ascii?Q?t5sNiXO+6BGlb2R59GhLcqN7Lpf02QCbFpT9vpeDKZPEbNoN7QQGKh3Eosuv?= =?us-ascii?Q?sErIxripP+G68rRys9HNWp+cZlzteKsrl3zi57OOTHEIdrFcjaeuk5MKyYOJ?= =?us-ascii?Q?aL907ELIubhz49CrEAHw7TZ6rRj7urJNE24rScugqMFWej+hwPftzZ6MZAS9?= =?us-ascii?Q?3FZTk4APQVVrwZWw/SurSF/WMRe7gputOSNSRm3JTNhKl4iS1xPgWRSKQYtp?= =?us-ascii?Q?ea6cM8sPrYRaqHcvv74vjOT3ktIJ9k0gU4pXhRiaJ0cMivbVjEdh0P1KWdr3?= =?us-ascii?Q?wJBGAj9G0hEDo86v0w7KRijehNNF31SCz4Lds4hmIwJQhxEMrufCkjWxKIr8?= =?us-ascii?Q?cNjNfRdhVHFplHewthMDPs4=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-OriginatorOrg: os.amperecomputing.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM2PR01MB9464.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: fabf0683-1e3e-491a-df4d-08de2641a514 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2025 01:27:31.7295 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3bc2b170-fd94-476d-b0ce-4229bdc904a7 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: VcWm0XvNS7VklgyaTF2QCHvRKzX6wwasy2/G0NJELiG9/npjypeBLvZa7yYmbl81NSCwL9R5mI9kwu3U78znBOLxiTxAoJBnL5f2W1t/WU3eTTGcxqt2kjvfNIb5jyw1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY3PR01MB6514 Hi Vincent, Makes sense, thanks for the clarification. The system I'm using is an Amper= e Altra which consists of 2-CPU MC domains (e.g., MC: [78-79]), all within = a single PKG domain (PKG: [0-79]). The shared cache is confined to the 2-CP= U MC domain and concentrating too much work on that pair can itself become = a bottleneck, best not to introduce extra stacking bias within the MC domai= n. I agree that `select_idle_sibling()` is not the appropriate place to addres= s the behavior I am investigating. Rather, it might need some refinement in= `wake_affine()` while choosing between `this_cpu` and `prev_cpu` across di= fferent MC domains. Thanks, Shubhang ________________________________________ From: Vincent Guittot Sent: Friday, November 14, 2025 5:36 AM To: Shubhang Kaushik OS Cc: Ingo Molnar; Peter Zijlstra; Juri Lelli; Dietmar Eggemann; Steven Roste= dt; Ben Segall; Mel Gorman; Valentin Schneider; Shubhang Kaushik; Shijie Hu= ang; Frank Wang; Christopher Lameter; Adam Li; linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] sched/fair: Prefer cache locality for EAS wakeup On Thu, 13 Nov 2025 at 01:26, Shubhang Kaushik OS wrote: > > > From your previous answer on v1, I don't think that you use > > heterogeneous system so eas will not be enabled in your case and even > > when used find_energy_efficient_cpu() will be called before > > I agree that the EAS centric approach in the current patch is misplaced f= or our homogeneous systems. > > > Otherwise you might want to check in wake_affine() where we decide > > between local cpu and previous cpu which one should be the target. > > This can have an impact especially if there are not in the same LLC > > While wake_affine() modifications seem logical, I see that they cause per= formance regressions across the board due to the inherent trade-offs in alt= ering that critical initial decision point. > We might need to solve the non-idle fallback within `select_idle_sibling`= to ring fence the impact for preserving locality effectively. So I'm confused about your topology; Could you share your scheduling topolo= gy ? Also I'm not sure what problem you are trying to solve. select_idle_sibling() is all about finding an idle CPU that shares cache with target with target being either local cpu or prev cpu. If target is prev cpu, we select an idle CPU that shares cache with prev and the cache locality should be preserved (at least at L3 level or even cluer level if you have one) If target is local cpu and it shares cache with prev, the result should be similar as above at L3 level but maybe not at cluster level If target is local cpu and it doesn't share cache with prev then select_idle_sibling() is not the right place and you should look at wake affine to favor prev cpu is some cases to be defined Thanks, Vincent > > Thanks, > Shubhang Kaushik > > ________________________________________ > From: Vincent Guittot > Sent: Monday, November 3, 2025 1:04 AM > To: Shubhang Kaushik OS > Cc: Ingo Molnar; Peter Zijlstra; Juri Lelli; Dietmar Eggemann; Steven Ros= tedt; Ben Segall; Mel Gorman; Valentin Schneider; Shubhang Kaushik; Shijie = Huang; Frank Wang; Christopher Lameter; Adam Li; linux-kernel@vger.kernel.o= rg > Subject: Re: [PATCH v2] sched/fair: Prefer cache locality for EAS wakeup > > On Thu, 30 Oct 2025 at 20:19, Shubhang Kaushik via B4 Relay > wrote: > > > > From: Shubhang Kaushik > > > > When Energy Aware Scheduling (EAS) is enabled, a task waking up on a > > sibling CPU might migrate away from its previous CPU even if that CPU > > is not overutilized. This sacrifices cache locality and introduces > > unnecessary migration overhead. > > > > This patch refines the wakeup heuristic in `select_idle_sibling()`. If > > EAS is active and the task's previous CPU (`prev`) is not overutilized, > > the scheduler will prioritize waking the task on `prev`, avoiding an > > unneeded migration and preserving cache-hotness. > > > > --- > > v2: > > - Addressed reviewer comments to handle this special condition > > within the selection logic, prioritizing the > > previous CPU if not overutilized for EAS. > > - Link to v1: https://lore.kernel.org/all/20251017-b4-sched-cfs-refacto= r-propagate-v1-1-1eb0dc5b19b3@os.amperecomputing.com/ > > > > Signed-off-by: Shubhang Kaushik > > --- > > kernel/sched/fair.c | 12 +++++++++--- > > 1 file changed, 9 insertions(+), 3 deletions(-) > > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > index 25970dbbb27959bc130d288d5f80677f75f8db8b..ac94463627778f09522fb54= 20f67b903a694ad4d 100644 > > --- a/kernel/sched/fair.c > > +++ b/kernel/sched/fair.c > > @@ -7847,9 +7847,7 @@ static int select_idle_sibling(struct task_struct= *p, int prev, int target) > > asym_fits_cpu(task_util, util_min, util_max, target)) > > return target; > > > > - /* > > - * If the previous CPU is cache affine and idle, don't be stupi= d: > > - */ > > + /* Reschedule on an idle, cache-sharing sibling to preserve aff= inity: */ > > if (prev !=3D target && cpus_share_cache(prev, target) && > > (available_idle_cpu(prev) || sched_idle_cpu(prev)) && > > asym_fits_cpu(task_util, util_min, util_max, prev)) { > > @@ -7861,6 +7859,14 @@ static int select_idle_sibling(struct task_struc= t *p, int prev, int target) > > prev_aff =3D prev; > > } > > > > + /* > > + * If the previous CPU is not overutilized, prefer it for cache= locality. > > + * This prevents migration away from a cache-hot CPU that can s= till > > + * handle the task without causing an overload. > > + */ > > + if (sched_energy_enabled() && !cpu_overutilized(prev)) > > From your previous answer on v1, I don't think that you use > heterogeneous system so eas will not be enabled in your case and even > when used find_energy_efficient_cpu() will be called before > > select_idle_sibling looks for an idle cpu that shares the cache with > target, Isn't such migration inside the same LLC good in your case ? > > Otherwise you might want to check in wake_affine() where we decide > between local cpu and previous cpu which one should be the target. > This can have an impact especially if there are not in the same LLC > > > + return prev; > > + > > /* > > * Allow a per-cpu kthread to stack with the wakee if the > > * kworker thread and the tasks previous CPUs are the same. > > > > --- > > base-commit: e53642b87a4f4b03a8d7e5f8507fc3cd0c595ea6 > > change-id: 20251030-b4-follow-up-ff03b4533a2d > > > > Best regards, > > -- > > Shubhang Kaushik > > > >