From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from BL2PR02CU003.outbound.protection.outlook.com (mail-eastusazon11021107.outbound.protection.outlook.com [52.101.52.107]) (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 1F6DF396B76 for ; Mon, 30 Mar 2026 21:32:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.52.107 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774906356; cv=fail; b=aqDSB5tm00EJjFEgkP2GMuH+qZckOddS3ttMMgh4ymvqWRT8DspwpUpcKHpRc4He3WK9IYu2VPYABuL6b7ntxnPQzvJz1okk7hcRlbtb8pukLu02dJZyDdc1xnxkBzW/4TtuUwfW/UZYSS1jtn7dunY8SOOcLPDnSRoW/PmzDWE= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774906356; c=relaxed/simple; bh=AQEBw81f0tc5shcj/1mKgSks6q9t8gDJ5tD31NpZCuo=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: Content-Type:MIME-Version; b=s9dT0J8q50QVyhE5bunvUC/mNUodbMzUiMUCOVXGK3Gj9kOHAdpBbj6dsfHZYZZEJlOxCW7iw9zNi6yf1vmPi8EM9kMNB5piWoJgmwUoRvhNB8Fx1lxmiVw7cdpWy9Am2amgnIfy/dUXQgNSbZhfnf/ITH+sYvM+S+RRrRXYmOc= 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=POTuqxHy; arc=fail smtp.client-ip=52.101.52.107 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="POTuqxHy" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=rfMQ0WR0R694UTpEoTaOlVy0pqMeLHvbmqpW+xtiKq5e9AH1JjlZm/1HD/8+zv6j74XMJ8NIefQmZON1dFQ4g2aD9sElhYqLJKUY1d+6wfBZYCg2oEyHUAAGSKBRt/6nuJEOkOHKQrAeGUT5r1eZkn7BhRUZNpQUNCE7y6PtegOh/jHStn/ISuaibg3hGcmkJn+eW0xJxKyYroJsI5Pp5ckVA9yFDQC+5oPnVBPCiA+UVXLoCIgigJQTvn1uYRH1MzzVEbjWM2wZCbA9nNAlUEnk6iHEkTFUg1LRvanoR2oUdfV/K2f+VGRP23VdKF7kJPR96YHgYAZxg8zYqo70VQ== 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=uYvTK2opbw4pvZmXdRsZBC36HS2EFUH6wHChgm38NAs=; b=q22tloLopdQvezJIGfAc9dXRHstsUuWJ6906DF9s4nGKUBkLaVGrSW9JzXxiYviSGDcNAiSwCdCVArrgq0S5BDQ7wn6VNZax7MqaqTeJ2e5MTlVFAt11CPr0uojmgvbZ0UN3Yyjueuv1482EQDNjvvTiLuZMYyDf8jKcRuTot1NNGojutxNz/yq4p15V5PXtN/+kPJA2v+VbNpbTYgNIOHT9w5X2Rz0ZhAzDJKPDzw5jrq9+/OApfhLXGU0vV4C+1VHTWSeGLyjH6jaulJAdKdUgitR89e2Gf3p9p4sLPegeX/d2pEEy3Z99ie2DiSJsPnA0x/ByU6QJvPmPTKFrMg== 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=uYvTK2opbw4pvZmXdRsZBC36HS2EFUH6wHChgm38NAs=; b=POTuqxHyIbOOsv7q8ch/2BPJR+ofVIpkFFEFYkfvONo8IX2gPHavOaBiP1nKR/Gf4qwCXZxfeuGViJQPdqd/eYN27x09/1MlUyRphEEQVe4XrbWsrGLzi1RGjN1AjQC6MgkJ2e18hn5CkZNoXwirt6J5jgtgST6OZLordg6cxuc= 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 CH0PR01MB7122.prod.exchangelabs.com (2603:10b6:610:ff::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9745.28; Mon, 30 Mar 2026 21:32:27 +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.9745.027; Mon, 30 Mar 2026 21:32:27 +0000 Date: Mon, 30 Mar 2026 14:32:24 -0700 (PDT) From: Shubhang Kaushik To: Vincent Guittot , Peter Zijlstra cc: mingo@redhat.com, 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] sched: fair: Prevent negative lag increase during delayed dequeue In-Reply-To: Message-ID: <8e6abb89-9fff-1410-4477-61505ca8e2f8@os.amperecomputing.com> References: <20260327180219.2879905-1-vincent.guittot@linaro.org> <20260330140653.GO3738010@noisy.programming.kicks-ass.net> Content-Type: text/plain; charset=US-ASCII; format=flowed X-ClientProxiedBy: CYZPR05CA0028.namprd05.prod.outlook.com (2603:10b6:930:a3::12) 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_|CH0PR01MB7122:EE_ X-MS-Office365-Filtering-Correlation-Id: 40163a09-5b4a-453a-288f-08de8ea3d6cf X-MS-Exchange-AtpMessageProperties: SA X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|7416014|1800799024|55112099003|22082099003|56012099003|18002099003; X-Microsoft-Antispam-Message-Info: fg1pHGce3nHcGisOKo2apG0uVsFNZYpn1+XvP8LA9T5GYaDM7JgpkUU7C3bXAiR1ZJd3mZFfUe2JOlk44I+S9hGG5wXE3gGkaY0esbdNnRuS8UgCO36tT9Kewi0ACPXA3XSeC26oL5bihx7I98/07tWpyk3ju6kGlg20TC3h9stIy2m6+FiUzlnEMJmzjwm4AWGfrUlhSrh1IMPi4czdStta87i7RIbh4gjPRHhLPBTO5AjePofRFFgh3pN/y/p8yo4GcDS4qhncgpe47f3s4rFPlzORaWYINWq6U6XycxhBNRCo+hIKXQdM1zye2zxlVb+CJ5Dzpdz3bjsUKSkVLxHQeiRNm+BkJX3vc6bu5rHFOw52h1Ae9oYgXZLvmeKrO/LnriIGMf8YVamymIc9FU/rtUtQoC45apSeSbqI//u1/bQp10i5s2y5R5N53Ogk1FxMlu4nEnNHTlva7sCLDQa9lNQ1EzeMNI0urAOZMIa3k3XVaOssXl7/FHWFdv8hEYJM5CKBrRxUJ9mt1DiTbBVWe81DR16VS6fBqt8VdFf/cOD9IM504bxhnik8yYxasNQ9AgeEi+mj1PzcWC+FexwtIXNuHuC22i2eUJFmJ0EqyDDuWq9PzOljVDaKyy/GCwUJf57U5emxUXgkNx//td57GiqsKTJaqGlD7qqT/FkuPXAR9esS3z/tmOP6AIeH4o3tHgxcFcjJTgXPQHHDnIfrHv/BKNryRaiBeD8xDww= 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)(376014)(7416014)(1800799024)(55112099003)(22082099003)(56012099003)(18002099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?7gUmVUMOO/8Qgby/TXLMybGFOLM3PoMK9hCBv27v1/Z6SvwcOhkUDj5jHunk?= =?us-ascii?Q?oFzKOgH1s7o57hPOCaO0VNUd6ca7bfJXPqbfYsqwMMbC9zsjKVD6OK703um+?= =?us-ascii?Q?Oy800PR1bilCaqG8JaA322P6OlfiyxzLST400GTlsuzV8cI8pOTcvPIQKuUw?= =?us-ascii?Q?tsMsN7M7/5cEXt31ZYWqfFbhCNpXG+VKI77U/JW3bwlIk9CwGW7qouA72mya?= =?us-ascii?Q?eF6Beqja513ni/RdXIv4ZB9FY2J0IR+zXVplGUI2cPJGkwQOVY5/cDG3e1JF?= =?us-ascii?Q?YT1m46agFyoTOfpYM6sU7XHSM/dAN4YK4BKA39hIjBJbOo4JlfOb9OMUT4Fk?= =?us-ascii?Q?dy4+3a5lDMVuRUe/l12CQSeTl4CI2B904IpE/xsmCtyLWG6128cwIQdWO/Ja?= =?us-ascii?Q?Zg9F4PUtdHSybFwWXLtQACTZYkAkjqgNhxpQM/wF2YhdPW81l/Gdfl9DOyQq?= =?us-ascii?Q?opX/VctdoizQa9oieE0u+HL/9vQAmpC/4S0c+ftD5reQ19a9BPzVALbU+vDH?= =?us-ascii?Q?JmLQ0lfYRyym8DKrym+J+DWg1xzI76N8BV+4VBYxa4ZNQkWgTYZjkhLgstPt?= =?us-ascii?Q?jhg9BNnTP+zZ1BB/3y0dx1tINfDNPtR4Pe2AyOVDK7snuBreatAuOmXeObMR?= =?us-ascii?Q?5skzdMc9rhlGoGLkxPalrQBkj59FbAvm+MQtf3kYQTYDYSjVlk2hQxEbPZQi?= =?us-ascii?Q?KY2mhRCJUxSiPRGprg5GOnAl0va1ghGeQEfKhDZ0nS4uiJPpQgZPzH8OKn7D?= =?us-ascii?Q?lzRaGs2Pd1J5A6bLv/hKcY7NHVXEOi8oS7zCt/1xE/ZPrAwxmMT46X2sHaRt?= =?us-ascii?Q?mifzWCLjvhS4VBYajSr3FwiB6WwCkvjQLijLo6HLTJWshigWQ9FEgZkFNHg+?= =?us-ascii?Q?U1pLNjNPWaOEGG33lG4z8jetufmnIm3vj9XyIqsereXMcidyU734x5jFPo27?= =?us-ascii?Q?cbulgTwlHBERE+9teoYvThu+3h/ePW0HEe5CA2TNL0aypXyFkHvTMdRTTI3+?= =?us-ascii?Q?2Jompw5YdI0YuX/ds5O/8OCyAHlq9VWHgcyFVY9Yd9pW7+pDxnlcQAxmEnMo?= =?us-ascii?Q?KM0A8ELaiyGN/K0aqD81o2X0DcO2i+5mgLWWXOF++h51LM6Luq99Rzjsb0uU?= =?us-ascii?Q?khFiV14ZaCW1PjXAAHbMGCLRsE0dj4oZ4PZgSvZ8AlHcbdSE0i9TQ5mo4zYg?= =?us-ascii?Q?qygrjeg7ppxBoGBDqCtWcFjLvmRq5hsuFTVcijm2+qBKE+1ceKY7561GfLd5?= =?us-ascii?Q?E0U3sE+pa5lQlfc7P0D/xW1g1RsYAzU6huEfBQI0Z9CNLOK73aLB76oIxjsN?= =?us-ascii?Q?L8yObTCsqx/gw6Gv3DhIvvWI3hCnG/z0EtsFRwfmTgxCKs1NUhcbtsbVBjl8?= =?us-ascii?Q?K9grG6ce69s4TTdqQsOl6sAc8yAoSXd8Nf6bfU7e+kW1EVI4PpimU5fKKcQk?= =?us-ascii?Q?9B+KUp0CQzj0+hXPq4i5Co1jDC5EW/kR7e5xAtXvBG1E060cZF7mPw232ZQb?= =?us-ascii?Q?4f5iD7NO58LH4+7njbWho7cxHY7QeuAwQfc+aM355JUQ5y5EMzFktNLJL7dB?= =?us-ascii?Q?9Tz+lQUTjIMdDgT++Ywno98HiXuliMJ4awrEwsLt+haUFJvw7g4DU8BugfEJ?= =?us-ascii?Q?D/tZvYJqhoLLmjf4EG9MNTYSeMArIAOGMO19h0Hon0V1LlMaSsM7tgGARFou?= =?us-ascii?Q?s27ojYHEVrrR5Q8If/HBC/VN+I6pf0u4WjRG7XjyhLPwI1IRZMVHoRzpT7ZG?= =?us-ascii?Q?menRRZddMTbHHsNdPI7+O/3I5rBuVw9YnXQxMHE+uu6UiZjCTefI?= X-OriginatorOrg: os.amperecomputing.com X-MS-Exchange-CrossTenant-Network-Message-Id: 40163a09-5b4a-453a-288f-08de8ea3d6cf X-MS-Exchange-CrossTenant-AuthSource: DM6PR01MB4953.prod.exchangelabs.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Mar 2026 21:32:27.4151 (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: G/HXRErucso4b3dyn/m8419gX1DnsueF310AZPa9b0pZ7PSqF3CB7PBxdoQRg+rlsxFR+hwCh2ewgS/JVy8P8oA7+HKmkmFB2YwQUoKutZ8SpUwOmEc6NUo7TvJOChtR X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR01MB7122 Hello Vincent, On Mon, 30 Mar 2026, Vincent Guittot wrote: > On Mon, 30 Mar 2026 at 16:06, Peter Zijlstra wrote: >> >> On Fri, Mar 27, 2026 at 07:02:19PM +0100, 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 delayed or not 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. >> >> *groan*, indeed! >> >> >>> Signed-off-by: Vincent Guittot >>> --- >>> kernel/sched/fair.c | 9 +++++++-- >>> 1 file changed, 7 insertions(+), 2 deletions(-) >>> >>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >>> index 226509231e67..efa9dfa8c583 100644 >>> --- a/kernel/sched/fair.c >>> +++ b/kernel/sched/fair.c >>> @@ -5595,6 +5595,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); >>> set_delayed(se); >>> return false; >>> } >>> @@ -7089,12 +7090,16 @@ requeue_delayed_entity(struct sched_entity *se) >>> WARN_ON_ONCE(!se->on_rq); >>> >>> if (sched_feat(DELAY_ZERO)) { >>> + s64 vlag, prev_vlag = se->vlag; >>> update_entity_lag(cfs_rq, se); >>> - if (se->vlag > 0) { >>> + /* prev_vlag < 0 otherwise se would not be delayed */ >>> + vlag = clamp(se->vlag, prev_vlag, 0); >>> + >>> + if (vlag != se->vlag) { >>> cfs_rq->nr_queued--; >>> if (se != cfs_rq->curr) >>> __dequeue_entity(cfs_rq, se); >>> - se->vlag = 0; >>> + se->vlag = vlag; >>> place_entity(cfs_rq, se, 0); >>> if (se != cfs_rq->curr) >>> __enqueue_entity(cfs_rq, se); >> >> So I think this should apply irrespective of DELAY_ZERO -- although >> since we default to that, it is the most relevant. > > I can try to link it only to delayed dequeue > >> >> Also, I'm thinking we might want a comment with this. We're bound to >> forget the details at some point. > > yes > >> >> Also, there is one other site that has DLAY_ZERO/clear_delayed(), does >> that want updating too? > > My assumption was that the other site happens when se is picked and > its lag is positive but we can sometimes force dequeue of delayed > entities. > Will add it > It seems finish_delayed_dequeue_entity() is another path where the delayed state is cleared. Would it be worth applying the same lag bounding there as well to keep the behavior consistent regardless of how the task exits the delayed state? Regards, Shubhang Kaushik