From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from CO1PR03CU002.outbound.protection.outlook.com (mail-westus2azon11010000.outbound.protection.outlook.com [52.101.46.0]) (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 EB82C282F1D for ; Thu, 14 May 2026 15:19:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.46.0 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778771976; cv=fail; b=NfFK5YgQ9M0SU5kYlS1cyqXuePvdM9z39Jgx+3qQrqQ9HW0OeMAxynNQv3qGuoGk8xUrjkGq4JBLT/WPYidtdlF7AN2y+qf70F93FNZt057KHIf1sjl1Ix0ZOTbKgY90GgO17cH1S+rMFWtIT4SVDlnIqJfFV2usLyZnPsJQIlo= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778771976; c=relaxed/simple; bh=xY3xHHLC2KBQinvn1SimtlZ5NTcsm6OXiqLSbZMaXSQ=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=sX6ChhrnZ+9rbE127t3bk+2vVJncWBoacB80k7OfkRO6NyPhEO4c8IcjDX44CHc9vEB6cS9ZWvRQZLK+kF1eXfcvrEHueMm0IeJghztwDc2BK8Bo3Ki7QSJ7hAj/nluDv4DD6H8/d0LfygptKcDuPUMLzv+AId9L8OFs2j6R9E4= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com; spf=fail smtp.mailfrom=amd.com; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b=XYBpOB8M; arc=fail smtp.client-ip=52.101.46.0 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=amd.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b="XYBpOB8M" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=bcfFqlDnyYAvO8TXXiBIUMc0vpt+V2RKYyb79+Kbc9opgEfhu2o/7BRxFaalWU5pCq+yPVbkJWUYYdnskDTIynv/CnY2/HuIv6kBqXNcbmK/ClbsFfoUepM4tsCr/m91gfcWv6syPz+1sLrbf+2ONW+RTvpXcKw0Xz7lydW7zxWEz5Sp0F7xMSwVLkN8Hn8KBwNFkUOTd4pF0c5jZdKQIYgt+pMpdW//PnMFoURXTnv8cEC5e/ceBZ04XKCEFesy0+KQklKuIuAnaR50VmxmLIahWrHiau9OjVNcYRV3u4e3RiOjv1oaJ4NGnmruWWDtvRIpc+SyV41djU/PMzTtrQ== 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=lOR6Xm6EUAJMDepXdwN0rcCM8k/s7BfsMEGJYXpUob0=; b=D52r5RcKjtpUHa7HjptT2GDH7AichfO6NVUx9dfrOs5SBUc621/RP5/4OlN7NEca/UV3WG7hi63Xr/u7voeeYas91j/s0EuMUoqdm9jhOUgUOnLyfvpkfzpZMal8T8T5WwmyNbrYM8A8EGy2Ai+8ghe12VNA9flfTdxr4P9VFcSyIk0O1CaRBmY1+VDID9D5zRCTMHC6OV+TO7IdBEBpPjCaeVuQpP1Kw8REK8Dx+m+qPIFM9yKcKxs1ER8w0AmzLRuKeyVIzRVktKM6S5OvDszK7XqZdyWkeZAGSw7RXiPGkbzOeKsWvs3UExat3hq8EG7zNp0VXuEFQoVGP4dhLA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=huawei.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lOR6Xm6EUAJMDepXdwN0rcCM8k/s7BfsMEGJYXpUob0=; b=XYBpOB8MTqtbPj1k9XWyySBVHwyWOgFTB85fB2MVWyisroyzNurndgIDws8VLA5rbPUNx63p+2uuMEPxLrMyTA1H1XOW1GoGj8g51tXJO5kwyVwBnpDKjdfwKXnJrwk/jSVw2epEfbhmnbGaLlwRpivIxZbcTCX2fC1cBP9Pk38= Received: from CH2PR04CA0013.namprd04.prod.outlook.com (2603:10b6:610:52::23) by SN7PR12MB7225.namprd12.prod.outlook.com (2603:10b6:806:2a8::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9891.15; Thu, 14 May 2026 15:19:28 +0000 Received: from CH1PEPF0000AD77.namprd04.prod.outlook.com (2603:10b6:610:52:cafe::83) by CH2PR04CA0013.outlook.office365.com (2603:10b6:610:52::23) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9913.12 via Frontend Transport; Thu, 14 May 2026 15:19:28 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Received: from satlexmb07.amd.com (165.204.84.17) by CH1PEPF0000AD77.mail.protection.outlook.com (10.167.244.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.25.13 via Frontend Transport; Thu, 14 May 2026 15:19:26 +0000 Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.41; Thu, 14 May 2026 10:19:26 -0500 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.41; Thu, 14 May 2026 08:19:26 -0700 Received: from [172.31.178.191] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.41 via Frontend Transport; Thu, 14 May 2026 10:19:23 -0500 Message-ID: Date: Thu, 14 May 2026 20:49:17 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] [QUESTION] sched/fair: Potential vruntime underflow and unconstrained vlag scaling in rescale_entity() To: Chen Jinghuang , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot CC: Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , References: <20260514132515.4009200-1-chenjinghuang2@huawei.com> Content-Language: en-US From: K Prateek Nayak In-Reply-To: <20260514132515.4009200-1-chenjinghuang2@huawei.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH1PEPF0000AD77:EE_|SN7PR12MB7225:EE_ X-MS-Office365-Filtering-Correlation-Id: 66b8defd-4ff8-4855-f3c0-08deb1cc2ff9 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|36860700016|376014|82310400026|1800799024|22082099003|18002099003|56012099003|11063799003|3023799003; X-Microsoft-Antispam-Message-Info: N+SccE4TW/IvHnrn3AZ5ZXwwBhWGEkH3qy1bgre+XzxC8OIym2XZlZHWF4481IbPsLFLHaHVLh7GERcsDQOzRA6KXF1EgVXxrc7BWMYR8eMzgjs+sPCqaT7eF1ctRZj+tlohbFHlUPt7HCk/iBv79CfXAXuLrujlXYSGUJd8n21OExvQa0351RqBzGF6GvvSeKsc6smUzK5i2qpt/YHN+S4WnbkIbIVQowc+xgJR4rfSM6YJ2/UiGbEz60ZwsS4XEhccO9LRibMz5tbNZcHtM3OCQEazH5zE05yR08n+InHmTGIqN1xzZAclOy3fowzTC3wpT2mzm2LdubQAVI3CMpuZjcBKof3VnPuJkjKRJx03Qn3GZC4tZdSdd9WLxG2NylNb/xIsMccdJRip4ypdnh8F5w3usVrEefUNLdWiRxDAOowOJiIVPjxu4yEHyVYIi7+h1KtpMS2wLDvYxcZtrZhAe2t+IQkaBsYlkfbqdAC5sT+HpfGDrtPcpBVpZHgMUxJ2fvNk1vW5a22rySW77lyA9K3N4EXXuQxXvpxGi6y5sd1sgQg9pfUj15yKrKsWCb8GpjtQUYHmA+eZfFJimrhl+9P+L2XM6LmD8NfSKNItTTzENUbQrOuHjxwkPvnvgD+ScUgfAbJxwD3qKg0xz5oe9AAXaO42YU4FAyMJRQMDM3+BmvXGR6fcPZ81AbSySST0n6N/8Hrc08MyYVDkvkxUhZst3SK1TN7rkON5Aw4= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(7416014)(36860700016)(376014)(82310400026)(1800799024)(22082099003)(18002099003)(56012099003)(11063799003)(3023799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 0mDWH6IvxEo4cMKfZdPmZGRvTTg+Jx+WrDAsEAOC/86on9hkAqrrJRbGBuoktAs6jV9si3cwT6PNKJb9SeTnLiuoPpdJZc57gNbj3MSoN7x3v94Sg2vHiXJ0ufEL3VKq6QBx0yIDooqzceEQy9IEJU+YMh2/KDW3t8XvlG9DYJ+uoVXOMeVJy+kkNSZ4qMAaCc0Qzk8KHo+cU315j7hNN7v5dB++SiBKR2PuSrkHhMIIhr+ZGZemEbGbhtvu83GvQv1RcgUWPSlykrfHr+ffT3nfhcUH4m1uJhSwALjA1r2cX5cxVDyPcfZ9iIRPRxQa8ru6jRRkh6F2YVE/T6oEeQUZjjbcK+K9HwyZItdhTswToKeVZaNxd96IK3hdqAyt5dLmwtpNYM0PHz4aXoncPe2tVMIgH16gh/Qgf8COGm1roRtmCU8DX9s1ZhYz9TyU X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 May 2026 15:19:26.8989 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 66b8defd-4ff8-4855-f3c0-08deb1cc2ff9 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH1PEPF0000AD77.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7225 Hello Chen, On 5/14/2026 6:55 PM, Chen Jinghuang wrote: > Hi all, > > While analyzing cgroup weight adjustment scenarios in EEVDF, I observed a > potential vruntime underflow issue caused by unconstrained vlag scaling in > rescale_entity(). I would like to consult the community on whether this > behavior is expected or if it represents a bug in the current implementation. > > I notice this my trace in a multi-level cgroup environment: > > CPU 3 > CURRENT: PID: 12485 TASK: ffff003027f49440 COMMAND: "cpu_sim" > ROOT_TASK_GROUP: ffffd714095439c0 CFS_RQ: ffff002fbfa3d140 > TASK_GROUP: ffff00211fdfe800 CFS_RQ: ffff00213f2c9800 > TASK_GROUP: ffff20300f2e7000 CFS_RQ: ffff0021190ca000 > TASK_GROUP: ffff203016880c00 CFS_RQ: ffff00211ece4c00 > [120] PID: 12485 TASK: ffff003027f49440 COMMAND: "cpu_sim" [CURRENT] > TASK_GROUP: ffff203016884000 CFS_RQ: ffff002156835c00 > [120] PID: 12649 TASK: ffff003027f4e540 COMMAND: "cpu_sim" > > Trace Metrics (Before/After rescale_entity and update_load_set): > > Before: weight: 209715, avruntime: 7738112562, vlag: 3638691801, vruntime: 4099420761 > After: weight: 614, avruntime: 7738112562, vlag: 1242814741118, vruntime: 4099420761, limit: 724001488558 > (vruntime/avruntime stay unchanged; the scaling only touches vlag, deadline, and vprot) > > Weight drop (209715->614) during __sched_group_set_shares() causes se->vlag > to explode in rescale_entity(), surged from 3638691801 to 1242814741118. > > When the entity's vruntime is subsequently updated via se->vruntime = > avruntime - se->vlag, the massive vlag value leads to a underflow of > se->vruntime. > > Furthermore, I noticed that while entity_lag() typically applies a limit (calculated > as 724001488558 in this instance) to constrain se->vlag, rescale_entity() performs > the scaling without any such boundary checks. This allows se->vlag to exceed the > theoretical limits expected by the EEVDF algorithm. The vlag, to begin with, would be within theoretical limits right? Rescaling it should also put it under theoretical limits if I'm not wrong. > > Questions: > 1. Is this se->vruntime underflow during drastic weight reduction considered acceptable > within the current EEVDF design? All the vruntime considerations use signed delta from the zero_vruntime so based on my understanding, it should be fine. > 2. Should rescale_entity() apply a limit check (similar to entity_lag()) immediately > after scaling the vlag to prevent it from escaping reasonable bounds? > > Something like this? > > Signed-off-by: Chen Jinghuang > --- > kernel/sched/fair.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 3ebec186f982..351e2f7b4b28 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -4046,6 +4046,15 @@ rescale_entity(struct sched_entity *se, unsigned long weight, bool rel_vprot) > */ > se->vlag = div64_long(se->vlag * old_weight, weight); This vlag is already calculated using entity_lag() which is within the theoretical limits and is being scaled proportionally. > > + { > + u64 max_slice = cfs_rq_max_slice(cfs_rq_of(se)) + TICK_NSEC; This should also consider if "se" has the largest slice since it is outside of the cfs_rq at this point. > + s64 limit; > + > + limit = calc_delta_fair(max_slice, se); update_load_set() is done after rescale_entity(). The above should actually scale the limits based on the new weight. > + > + se->vlag = clamp(se->vlag, -limit, limit); If we use the updated weight, se->vlag should already be within those limits. > + } > + > /* > * DEADLINE > * -------- -- Thanks and Regards, Prateek