From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from PH7PR06CU001.outbound.protection.outlook.com (mail-westus3azon11020109.outbound.protection.outlook.com [52.101.201.109]) (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 3DDEC36C9CB for ; Thu, 2 Apr 2026 19:27:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.201.109 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775158047; cv=fail; b=dZ7lwT1rbLTNlWg2ADdthgT82TuO61/zhgJlXPetFFmxNrvn4+Xa9d25You/FAcTWDEx82Vt42AeD4rkxiiBPhADNT6pvf3HNbSv6SA6NuNVckw8CHVmQb+ATtOaD56IKwlMwLGF4cIf7COmoBb/V0ehtdd/ilE85HhHnE1ZdzM= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775158047; c=relaxed/simple; bh=u/5cqqixAh1mAFbKVCFybDtdiqk0l3waaYhSYwBVMiA=; h=Date:From:To:Subject:In-Reply-To:Message-ID:References: Content-Type:MIME-Version; b=P78vMb2Jx9MImhYn+xb52UZL5VfMPkEYJFYG1sOaWDODenA15zxK9u23Tc9dpaIKmOKXyVcaVhZGqkOwRRwFpdJ/g+PHqhl4v/lINrEGM9rKw4ErVG5y4w6OwD0wHMXzH9YdGv2IHRnbJ9TW/I+U8XGmfnyCEUCqDMe1iaqHTp8= 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=rZX4fL7t; arc=fail smtp.client-ip=52.101.201.109 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="rZX4fL7t" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=CxJgF2fA+tHSt78i1bT49rMSXAG+3GhLJxQcEjkoo+6d2Z4ebegjOxIdn2PgyOpXBE+0xiGI3ZMTFqn4pmxAwFrZZX73bHkU1pXBe51CNBvdGIHytlcretLvtH8sVvZ/RZna7fKQTkdeUsCmjSTsBT2eRAgAZzK1h8rjSFnSSYiuOGy5lA9qElRbsh68NRy0PEdgK/zbOPa69uujzQesiwecjLTbrDsca211xHwegH2lSf0pngbHSAdOUWTRPt774WehgSOo0Q5wrzC5oKSGAkNsfnPhQD/EYMTyIsP314tuX7k6WWqe8uiTU6g+1Lkj8rRI54wQnmVk06OTOPqelQ== 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=jPZ03nXhk287msdn0Re91ZjH2A0rNU/9bSqzZ082kQM=; b=cXowgg4rxU+RzBU4o/14MtJHJ3tQGntYogrhOYgPkCapy9cNQ25En3x9lJHKd5FHThONaCCTIHPTnSyPv8F89vQVD5syysJtPaaOhN1bKLAFWq38HFHcZJugt/NjCI1ATyRM74meNbsQteVZehj0gyBvtGFEu2aqzcuJkiZRq3Utxf9HtUNRxAUAJVwDpSBCRBFlY0PHbdYbPy7FSTuC3EdnMyiY44r0wXiUeX+RbyXmRzpClvz0NaVqJEsYybph4J9cSPNV2mYkESMTo6opCAqPPhwQa4226bCJSU1Ysv8E601kr2ZHFlEIkU+hKtnTasyugFFdD7UX8N64hEMUUQ== 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=jPZ03nXhk287msdn0Re91ZjH2A0rNU/9bSqzZ082kQM=; b=rZX4fL7tKbJvltnG8bLSwWJkeGXn6PkyFVksDpza19w/NLWIAl9P5o3Q+ECXsIh+UV8p+p0mr3ER5ZIafMKyFgsPzEFDdqwZSXO2+NUD1BYKEFE1lRyWODoQyMzg/7XzCC1JL5pPIh/e4ggRn1SKXQIlUFtxumuLKgXfVBua6ss= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=os.amperecomputing.com; Received: from DM6PR01MB4953.prod.exchangelabs.com (2603:10b6:5:8::15) by CYYPR01MB8334.prod.exchangelabs.com (2603:10b6:930:c9::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9745.23; Thu, 2 Apr 2026 19:27:21 +0000 Received: from DM6PR01MB4953.prod.exchangelabs.com ([fe80::4d2:1a2f:e4d1:5f7f]) by DM6PR01MB4953.prod.exchangelabs.com ([fe80::4d2:1a2f:e4d1:5f7f%6]) with mapi id 15.20.9769.016; Thu, 2 Apr 2026 19:27:20 +0000 Date: Thu, 2 Apr 2026 12:27:16 -0700 (PDT) From: Shubhang Kaushik To: Vincent Guittot , mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, kprateek.nayak@amd.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] sched: fair: Prevent negative lag increase during delayed dequeue In-Reply-To: <20260331162352.551501-1-vincent.guittot@linaro.org> Message-ID: <2668574e-fefd-2d13-4fcf-39205ca9efb8@os.amperecomputing.com> References: <20260331162352.551501-1-vincent.guittot@linaro.org> Content-Type: text/plain; format=flowed; charset=US-ASCII X-ClientProxiedBy: CY5PR03CA0031.namprd03.prod.outlook.com (2603:10b6:930:8::28) To DM6PR01MB4953.prod.exchangelabs.com (2603:10b6:5:8::15) 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: DM6PR01MB4953:EE_|CYYPR01MB8334:EE_ X-MS-Office365-Filtering-Correlation-Id: 777c7fc7-60d3-4165-0a63-08de90eddade X-MS-Exchange-AtpMessageProperties: SA X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|7416014|376014|1800799024|921020|22082099003|18002099003|56012099003|55112099003; X-Microsoft-Antispam-Message-Info: layx7GjVSf1n1taqfNFi8rK6uvty6pjJuL3q7S/xtSkm8cF3WxxdFDqp587Ll9lkTrmDpYO5gW/X6F7Am96pqM04yDTMmDfO692PCeVweOEx+fnFbh53KkeBvvAQPWa8NQKLb/e1Ex2WaGwzFIlaxFyxn4aJjaG+5zf928DEZvSamA3lRXHZdoDC81x45Ii4AtL9PLWdmXZebKBZTQjRFkU81rLMgqyw7S2FnGivBAX2HzCJlph+xzpvpIpCMCZTHBuWEyU57yyboIxj6iPPl1RAJkDPaQd90GqZ5wR4zMonnnlYCJMtNetTBywhBooJP3p6D4iiMOWsiNohsy+DGfXOrgbRSv02BZw/BTvtLNrrbmscygEg3BsGS9+kBL2AjpbjQWP21gEzJggD/LePK/Vh2Q7frkYCKEmpU194ipLyBOJgpfCDnHT8HS6OXbgRkENjISBuwldnqDNZ0Zz4mFbUIKZutrieWGJD5jiAvTmB4V0c+y6XwOFHSMtrofyLY8DQpAZr8XUXCDaG07GL77zRCQ1BO6Dbux12tKMKRVmseVHISaOj4LKTMnarAW22LzNY6zyeEBir0QmLEkBx1QnWq2MWjz8MVdNLbMx0DauJz4iXLG0ASzFKtvpojs9D9G3++TFjsdjzcMDNIAcQhKZC3GUx/c8HF+6PsRHuIvLGfmv0dRTx0QiBbAaGpXvs5qghy2yBvnmNb5cPp27aD+72va8SKw3b3CM8gBURFawsAtq56eHxq2oPTPoaSPrI27sQmpqV/2APx/WeHMDXdw== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR01MB4953.prod.exchangelabs.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(7416014)(376014)(1800799024)(921020)(22082099003)(18002099003)(56012099003)(55112099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?P9qq+5MgDx3ZApJRj9W3M93MgRFMOjMxPxeEEoWq3xatUO2cnkKcaXTZnryx?= =?us-ascii?Q?THaMzDZ9u2L60Una2PHYklT9LAANLNN+qivcJFIbP3QYO9bLNJAPjAnVmt5s?= =?us-ascii?Q?rCQR0CKBX9xoxyIwt8uHeh4BqRAH6UOzY0eR+qS5JjZYjgQ+smgbwVfiibcX?= =?us-ascii?Q?Gh6ugW1Do5CdK4TzUA2Mzb4MQ2TCu7GBfx28XAjv0GL3uEVhTmZUfs4FEXd9?= =?us-ascii?Q?5djDIm7ndfjVjWfEa5IB7PidIbBtUaOEsHxHg+FAOYBlmwOJa3kQhzES87sD?= =?us-ascii?Q?6sGCMUc7k9pXXtMUTytIHHjcIvlOOkBQp8VQBI0bI0NCTSknKL/JAHOqSt5l?= =?us-ascii?Q?sTgf11Ry8omGy/xJuMyPUSl6czLznZKj0Pm7s4TRVEfpWAIJ2Q5BdDGD4FmO?= =?us-ascii?Q?Rk8lNab+fOjafJri5+wcgwiggNo0H1kHTEMpIq8y661CwNVmduCbA7z0U8jv?= =?us-ascii?Q?2XIVhpi4pIv/SS0XTbK/M5UxuIgzw6fLEUZnehE3lEm4xsNPwqPCItCywGyM?= =?us-ascii?Q?mB39DXmnnsFJoJm2Im+FXhmERsr+ZDl9EHOH3l69CdhVmWb8y5jtdckhzn0E?= =?us-ascii?Q?gN1NXPogwV4RQKsbWzezglrKslDzgJQAElRYpi5o3VCko6jjq6zziHIj+gX3?= =?us-ascii?Q?CGb2ZAqzI+p9BYhDBwOLbBmgI5KOB7rF3xzYx1ArzkZ+VxBe3TN/pcGomerB?= =?us-ascii?Q?4/r3iP2YcLrLf18C4h3zm1rvmtoIyyK3VL0bzvmgFO8LoT44UPDMg6r9UKnz?= =?us-ascii?Q?3EGiekmCTyaA+SZEfFy7sfpnqiNjVziHfcioUNwczapAUWlmb0HfIFmXVdJ4?= =?us-ascii?Q?IEJpkRqDxSNSpFZq2gRSAmaf3M2EMueINCO09ItFbVnWSa2J2grJUDTni5gZ?= =?us-ascii?Q?9yrMcSpzpAuf7UECJlaUg01/IDL3KMnFZh3fMw+eXdaoUBm4fJ3fNhwtfmap?= =?us-ascii?Q?MjBHUfEpfHf3QOr64w3n5FwiJnjhWxRd/hTjodvPM2fIVhZB6+otyuxdvZ+K?= =?us-ascii?Q?NDFKLNbzc2qz8Ut0Y9jIDXCixE238LJKSoMz63dWaylCVEaPf+aso/jgRY/Q?= =?us-ascii?Q?Kuao3y9RRwsClgU6auOK3VFxYlLuBOSoav9ufuCXDSB8lR5RffnSZwoh2XA+?= =?us-ascii?Q?d9keDRz6EA+lKg5S1taegLuaWQnP0WrDVt+y7nQGtZgP2bE3HoaRrPp0HjSB?= =?us-ascii?Q?PEBbW/+XvogZE0qsP1WLbJX4ANjQxCkn0NVMafCF3xCiCVcPsMa90Gfu0R9h?= =?us-ascii?Q?2TTqURQlmtAyIFh/4KPbeLWAAP64WP42JM5EQeV1KB5MRDrlxAqHQ4ZrED5M?= =?us-ascii?Q?GVSAg8BCQ87o77sYUV03lGcn31SjtF3ZmVcjGu71xYN6Tyk05qvKLhjUFh6A?= =?us-ascii?Q?WdzNnLW71tZh5HkUEzhiqTn2cI5Rfotty4z90E/EIRhSNduS5j+9+OQtnaDm?= =?us-ascii?Q?LumAldcNOlYlf/YleBl4CT8ZPzEgpSGu+DUjVIEq5KFq4wSygfJ2w4zx9ZmD?= =?us-ascii?Q?z4DuXPnUKGOyBd/BSwoy9eZ8+ffLj5+p9p7Uz3AyR1iRL48nBdyHbh0FDfRx?= =?us-ascii?Q?OAXU0KIHZvWNiFt9o1LeqJBc00Abf9tS7t+mGKsDyGZCh/LhYzev8aeSAR9j?= =?us-ascii?Q?D3WFYKF26/i81Z+0tL65beWTTr63+e8riNXHEr9ytcdsC+sIowfhh1D7AP7k?= =?us-ascii?Q?o/JSvOaffrhT2N6zlZyhtyrGWQiZOlwq/th6QzLRtPPqvH1j5AJHCwaQ3OAg?= =?us-ascii?Q?PEYqwWaO5NSJ3yQTti7o//qXFkRS5tf/wCn5p3xwnHvngi4JBfIw?= X-OriginatorOrg: os.amperecomputing.com X-MS-Exchange-CrossTenant-Network-Message-Id: 777c7fc7-60d3-4165-0a63-08de90eddade X-MS-Exchange-CrossTenant-AuthSource: DM6PR01MB4953.prod.exchangelabs.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Apr 2026 19:27:20.7711 (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: wklKBIGBnlMZwM1o79Z6kTnahy+UeikuTTDsA/fuMnY7sXRv4T+JLNqBgDJ+T1kkKG4MrpDSvoMbscri1fgVWwDe1LliNLmIMVyl+MhkVIPNalzQ0p4Lii2esf7lZEPE X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR01MB8334 Hi Vincent, I have been testing your v2 patch on my 80 core Ampere Altra (ARMv8 Neoverse-N1) 1P system using an idle tickless kernel on the latest tip/sched/core branch. On Tue, 31 Mar 2026, Vincent Guittot wrote: > Delayed dequeue feature aims to reduce the negative lag of a dequeued task > while sleeping but it can happens that newly enqueued tasks will move > backward the avg vruntime and increase its negative lag. > When the delayed dequeued task wakes up, it has more neg lag compared to > being dequeued immediately or to other tasks that have been dequeued just > before theses new enqueues. > > Ensure that the negative lag of a delayed dequeued task doesn't increase > during its delayed dequeued phase while waiting for its neg lag to > diseappear. Similarly, we remove any positive lag that the delayed > dequeued task could have gain during thsi period. > > Short slice tasks are particularly impacted in overloaded system. > > Test on snapdragon rb5: > > hackbench -T -p -l 16000000 -g 2 1> /dev/null & > cyclictest -t 1 -i 2777 -D 333 --policy=fair --mlock -h 20000 -q > > The scheduling latency of cyclictest is: > > tip/sched/core tip/sched/core +this patch > cyclictest slice (ms) (default)2.8 8 8 > hackbench slice (ms) (default)2.8 20 20 > Total Samples | 115632 119733 119806 > Average (us) | 364 64(-82%) 61(- 5%) > Median (P50) (us) | 60 56(- 7%) 56( 0%) > 90th Percentile (us) | 1166 62(-95%) 62( 0%) > 99th Percentile (us) | 4192 73(-98%) 72(- 1%) > 99.9th Percentile (us) | 8528 2707(-68%) 1300(-52%) > Maximum (us) | 17735 14273(-20%) 13525(- 5%) > > Signed-off-by: Vincent Guittot > --- > I replicated this cyclictest environment scaled for 80 cores using a background hackbench load (-g 20). On Ampere Altra, I did not see the tail latency reduction that you observed on the 8-core Snapdragon. In fact, both average and max latencies increased slightly. Metric | Baseline | Patched | Delta (%) -------------|----------|----------|----------- Max Latency | 9141us | 9426us | +3.11% Avg Latency | 206us | 217us | +5.33% Min Latency | 14us | 13us | -7.14% More concerning is the impact on throughput. At 8-16 threads, hackbench execution times increased by ~30%. I attempted to isolate this by disabling the DELAY_DEQUEUE sched_feature. But the regression persists even with NO_DELAY_DEQUEUE, pointing to overhead in the modified update_entity_lag() path itself. Test Case | Baseline | Patched | Delta (%) | Patched(NO_DELAYDQ) -------------|----------|----------|-----------|-------------------- 4 Threads | 13.77s | 17.53s | +27.3% | 17.16s 8 Threads | 24.39s | 31.90s | +30.8% | 30.67s 16 Threads | 47.92s | 60.46s | +26.2% | 62.53s 32 Processes | 118.08s | 103.16s | -12.6% | 101.87s > Since v1: > - Embedded the check of lag evolution of delayed dequeue entities in > update_entity_lag() to include all cases. > While the patch shows a ~12.6% improvement at high saturation (32 processes), the throughput cost at mid-range scales appears to outweigh the fairness benefits on our high core system, as even the worst-case wake-up latencies did not improve. > kernel/sched/fair.c | 53 ++++++++++++++++++++++++++------------------- > 1 file changed, 31 insertions(+), 22 deletions(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 226509231e67..c1ffe86bf78d 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -840,11 +840,30 @@ static s64 entity_lag(struct cfs_rq *cfs_rq, struct sched_entity *se, u64 avrunt > return clamp(vlag, -limit, limit); > } > > -static void update_entity_lag(struct cfs_rq *cfs_rq, struct sched_entity *se) > +/* > + * Delayed dequeue aims to reduce the negative lag of a dequeued task. > + * While updating the lag of an entity, check that negative lag didn't increase > + * during the delayed dequeue period which would be unfair. > + * Similarly, check that the entity didn't gain positive lag when DELAY_ZERO is > + * set. > + * > + * Return true if the lag has been adjusted. > + */ > +static bool update_entity_lag(struct cfs_rq *cfs_rq, struct sched_entity *se) > { > + s64 vlag; > + > WARN_ON_ONCE(!se->on_rq); > > - se->vlag = entity_lag(cfs_rq, se, avg_vruntime(cfs_rq)); > + vlag = entity_lag(cfs_rq, se, avg_vruntime(cfs_rq)); > + > + if (se->sched_delayed) > + /* previous vlag < 0 otherwise se would not be delayed */ > + se->vlag = clamp(vlag, se->vlag, sched_feat(DELAY_ZERO) ? 0 : S64_MAX); > + else > + se->vlag = vlag; > + > + return (vlag != se->vlag); > } > > /* > @@ -5563,13 +5582,6 @@ static void clear_delayed(struct sched_entity *se) > } > } > > -static inline void finish_delayed_dequeue_entity(struct sched_entity *se) > -{ > - clear_delayed(se); > - if (sched_feat(DELAY_ZERO) && se->vlag > 0) > - se->vlag = 0; > -} > - > static bool > dequeue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int flags) > { > @@ -5595,6 +5607,7 @@ dequeue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int flags) > if (sched_feat(DELAY_DEQUEUE) && delay && > !entity_eligible(cfs_rq, se)) { > update_load_avg(cfs_rq, se, 0); > + update_entity_lag(cfs_rq, se); The regression persists even with NO_DELAY_DEQUEUE, likely because update_entity_lag() is now called unconditionally in dequeue_entity() thereby adding avg_vruntime() overhead and cacheline contention for every dequeue. Do consider guarding the update_entity_lag() call in dequeue_entity() with sched_feat(DELAY_DEQUEUE) check to avoid this tax when the feature is disabled. > set_delayed(se); > return false; > } > @@ -5634,7 +5647,7 @@ dequeue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int flags) > update_cfs_group(se); > > if (flags & DEQUEUE_DELAYED) > - finish_delayed_dequeue_entity(se); > + clear_delayed(se); > > if (cfs_rq->nr_queued == 0) { > update_idle_cfs_rq_clock_pelt(cfs_rq); > @@ -7088,18 +7101,14 @@ requeue_delayed_entity(struct sched_entity *se) > WARN_ON_ONCE(!se->sched_delayed); > WARN_ON_ONCE(!se->on_rq); > > - if (sched_feat(DELAY_ZERO)) { > - update_entity_lag(cfs_rq, se); > - if (se->vlag > 0) { > - cfs_rq->nr_queued--; > - if (se != cfs_rq->curr) > - __dequeue_entity(cfs_rq, se); > - se->vlag = 0; > - place_entity(cfs_rq, se, 0); > - if (se != cfs_rq->curr) > - __enqueue_entity(cfs_rq, se); > - cfs_rq->nr_queued++; > - } > + if (update_entity_lag(cfs_rq, se)) { > + cfs_rq->nr_queued--; > + if (se != cfs_rq->curr) > + __dequeue_entity(cfs_rq, se); > + place_entity(cfs_rq, se, 0); > + if (se != cfs_rq->curr) > + __enqueue_entity(cfs_rq, se); > + cfs_rq->nr_queued++; Triggering a full dequeue/enqueue cycle for every vlag adjustment appears to be a major bottleneck. Frequent RB-tree rebalancing here creates significant contention. Could we preserve fairness while recovering throughput by only re-queuing when the lag sign changes or a significant eligibility threshold is crossed? > } > > update_load_avg(cfs_rq, se, 0); > -- > 2.43.0 > > Regards, Shubhang Kaushik