From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from BL2PR02CU003.outbound.protection.outlook.com (mail-eastusazon11011052.outbound.protection.outlook.com [52.101.52.52]) (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 C65FB3346A1 for ; Thu, 22 Jan 2026 04:38:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.52.52 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769056738; cv=fail; b=kdj/N7a1L6UdEB1oXEk8i5CyxIfkf2gs0c9xfo3lEuugU07xnCS7Zt4vouV1dNDBq2GhA/StM44OlyBv6dpRk+K+V1NeOuGqJ9NetRioxz5SvuJNtJOGpQDyOCbDwjQibeWIyXLitKdAOWd5zktC8DK/B2oGA+6uLbXyybFeyRM= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769056738; c=relaxed/simple; bh=/C0P1+8JxSP2TZmBmWx1GEI/H1+K8DUr0IYCGSr7aVs=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=DBo3F0GUsoXywHjI0wDOpH0KjwPtGhkDwxlTkySvl55vPhMYc0NBrCN3ODARqND7jOkX8gKDeZ3kuV3GPGLyU9tr2N5Ov2ucpOIY5D7ccULHYTd9MiUue2C+GmwvZC+0FvL5g3GkLD0DOyLONnA49HQD6ziZ5kKIyqijTGlI0A4= 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=S7M0TNrc; arc=fail smtp.client-ip=52.101.52.52 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="S7M0TNrc" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=mtof+6E6Rr+zo99u2QHClUDSwvfBvevJJRlX9KtecSlhvvRUJ0W5o8/3KNdDxmDdrIXKPgLsz1VYn1kdXQ5fASvdmHVceinpHwIJGJcfDvZuBmJlow1NHIAP/poAKp2QFj4xWhWYqjwCLMuaO1h3zbREReBlNJqnzlgtnmm8zSckG7bk+y6r+4mXf9VUXnkfSR9GtJGL8D2D29PKZsirUxKMhqGHjKsRlK4x3gqD6wy1g7RtVhuqXVVCE9+2k2CFIXSSEyo/aQ+oE3BGHdpFAe/+ZNLWNVZZOAzxdgvDRxtpI0MAIuOz6tc5CWdkroGjnpbuNdI4Dax7BKjKCqwjvA== 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=+h0rjChJyXW6zm3ZublFKDUUuiyYsIaBJjfUflxs0Yk=; b=G7z8maoTSVZ6UnTflCn65/pNKUEE0SAiF5QgcznxGfmXinRN1jORzh9BIneqYwnAWSBvwUrEoGPkkmZ6lGuZx+kYqyxMBt1bS0X86UoqfGFN5rrClQ8XaaAdTX71LRX4ZujszctiQg0Th099m5PriG9fcz9bj81HN0U0NY8Vv9Vda/4u+8eplVisr9wd+Ko6E57ydWGJ6w0At93ykSQWIVAg3RrOq6w9J9eXdugic/0LuEOk/LRGqslIeTEb9fW3ZI+r/gs6pLf/W4eHyieq/+/Vq/nMA73dBEh1UpYfXEQxGIg0bPkUlf8mbUF9rhUdPOGIJg7srHiofynPeoiCcA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=linaro.org 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=+h0rjChJyXW6zm3ZublFKDUUuiyYsIaBJjfUflxs0Yk=; b=S7M0TNrcECT/hwwFyZWD2gvkL0fxCz4XvJNrt7DvgIE8KWtUruzk7QRiW0Vwsgu0Jqq5HPi+DsZ+rHjllvQBLV3jcOYmZ+LZaaLsslXbUJzlGAgOZl3fH6jIxFn2SceJtBuNtZc8PWnb2rKY9hQbCmuEXTPTafZv0t+OK0iR/EA= Received: from BL1PR13CA0368.namprd13.prod.outlook.com (2603:10b6:208:2c0::13) by IA0PR12MB8648.namprd12.prod.outlook.com (2603:10b6:208:486::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.9; Thu, 22 Jan 2026 04:38:52 +0000 Received: from BN3PEPF0000B373.namprd21.prod.outlook.com (2603:10b6:208:2c0:cafe::1c) by BL1PR13CA0368.outlook.office365.com (2603:10b6:208:2c0::13) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Thu, 22 Jan 2026 04:38:52 +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 BN3PEPF0000B373.mail.protection.outlook.com (10.167.243.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.0 via Frontend Transport; Thu, 22 Jan 2026 04:38:52 +0000 Received: from satlexmb08.amd.com (10.181.42.217) 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.17; Wed, 21 Jan 2026 22:38:52 -0600 Received: from [10.136.37.139] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Wed, 21 Jan 2026 22:38:48 -0600 Message-ID: Date: Thu, 22 Jan 2026 10:08:42 +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] sched/eevdf: Update se->vprot in reweight_entity() To: Vincent Guittot , "wangtao (EQ)" CC: , , , , , , , , , , References: <20260120123113.3518950-1-wangtao554@huawei.com> <8e7aadf8-b7a0-4500-ad2d-507665007694@amd.com> <15d8374f-b1a5-4946-829d-8e9c6ef39272@huawei.com> Content-Language: en-US From: K Prateek Nayak In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PEPF0000B373:EE_|IA0PR12MB8648:EE_ X-MS-Office365-Filtering-Correlation-Id: b1fddbf7-b55b-4fad-c2e8-08de597024d4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|1800799024|36860700013|376014|82310400026; X-Microsoft-Antispam-Message-Info: =?utf-8?B?YkMzN1FDUXdXenVqcEVOTm50S2h2MXVxbERGYkNtNWFuZTdLZDN1ekNFc0l1?= =?utf-8?B?ejUzVVVUTzhZUGVJNm1KZmRtM2ExRW5QVktZRjNoMHlwdkE0cGlCd3U2ZzZ5?= =?utf-8?B?emQ5RTJQUTZRQklGZDdQTk1rZVBzNmZEMStQSDc2dFJVZTBxaDk2TzIvbEZw?= =?utf-8?B?SFdabjd3Y09Ob29jYlRrODFuVXBwYzRxZm9iRzN0b3N1VFhna1d2M3RxeERZ?= =?utf-8?B?QmorYUVocDdCRnBnb0E4bTNtd0R1NUxjbW16Umx3c3dwOEVyV0JuMXl5Sldm?= =?utf-8?B?RERVN2ZDSlRSLys1dDl3R2VxU0tBWk5vSzhEUk9MclJXcHZ4LzVMYzVMeGRt?= =?utf-8?B?NldmblZyVlVyWmN3SVdkT3ovZ3ZYZ2QwM3B0TXlGUFU4VklrUkE5WHRsTzJI?= =?utf-8?B?Mkx6Q0xMMXROU1NUYzZtSVFqUEt0U2RrQTNKSnVmTjE4WHNlTnNwVFRsNjlU?= =?utf-8?B?RkFkT25UcEFWdFc4bmRKNWlNZGE0OVFRejhzYjRKcnBSTUp4aXA3eUZqTkE1?= =?utf-8?B?QlFKZDgxUFR3SDNYa3BxKy9TN1lDcHczbFpweTc5MVgvT0dSdy9UejRMSGoz?= =?utf-8?B?KzU4Q3V6b0NxbWZqL2orendLZzlhaE42MC9mRHRGVlVrRGIzRTd2NXI0c3ll?= =?utf-8?B?TG84RUhGeWp6aE9sWDlqQ3Fjc2ZvVGFTWmlQV1djMElNMXNyZEdyb0srZGd0?= =?utf-8?B?c0QxUnZSNWhiSG5YTTBNZTI1Wmc4dXlhaGo5dUdzY1ZOVllMMXgwNFc0UTI5?= =?utf-8?B?ZkNsWUdXcEd3WGNYOE1jTTNVZ0FrcDdieU9tclV6d05ncG1ERHFQT3VqZysr?= =?utf-8?B?SVErRm1uM29nUGJ0NkRqcmJHQjV4ZkpxbllMVk5wd3lTNmlMVGZEYW50eEpG?= =?utf-8?B?aXNUVEhVc2RtckdBakVKNEgxUW5kc3hYOWR2ckVrTktVNVlxZXNXY053UGV0?= =?utf-8?B?Vkk0KzhnMFpCVGZQSXB1QVU4cUtaYThNUlEzRS8vdG9hTStoVG44WEtTR1pV?= =?utf-8?B?NFMyWWhIRWpRa0NVamtqejBhTEhNaFVsdDJsajlJUmppSmcvaWU2MTRGV29y?= =?utf-8?B?eE9RZjhrcFNPcG1iZ0hXbFRRUHpueUtMRzE0OXNEM05CeHNCSUFYWms3MzRD?= =?utf-8?B?cUszVGtvclNRem5ENURaTm1jK2VrNndmVXVEcTJab0hKZE52SHV1RHRvdUYx?= =?utf-8?B?aytldXRSdm84SDBpa2RZbE9UWmtVLzlBSHZiUzA3QnhmQkdycktWeGRMdkFt?= =?utf-8?B?K2VKWEUyamoyZ0wzY0dITGZWaVVYSU5RVys0TFhUMlQwcWwxOFhBN0QxVWI2?= =?utf-8?B?aVJKMVhrbGRJc0dPUGQ0QTdjdnRjK2dOQ1lBd0NVZ1ZHZFQ5RDJnbjdZMVZj?= =?utf-8?B?VnhhR1huVS96aFN3MlRDZktjT1JLUW0zcHFXQzNoUWJxOXZZQ1RhSnVHQlVm?= =?utf-8?B?RS9nbmovcUNNalZDa2NqY2c3UUFTd05kT1JEYUoxWGYySS9YZTRJV0pXTy9q?= =?utf-8?B?b2R5MHNiekZMeG1iNkRSaTk5UmM2VDZCZWpJd0YzSFoyZUJlNHVPL3o1MWR4?= =?utf-8?B?QUtPenpWZlNmTUllUjZIc1RUUkxTNkhwM1V1NnRLZmRwNm40VVdhNkpPbjJq?= =?utf-8?B?ZHAvL1liRFZpcmN1VE5LR1REd1lNY0EyTEZSZzN5NmNkUlNrU2dvckRoMDVs?= =?utf-8?B?STM2N1B1L1R2MGM5aWNJZ3dud21pZmltZzQ2Y2svcTFPblZzZ3AwYjlrWDdP?= =?utf-8?B?T2RvWlZlNGRJRnRwMHloVEwrZVdGeEIxZlhzTnozbnEvL2kwRVRjM0ZSVVRM?= =?utf-8?B?Q3pQbDFDK08xaDdhVDZtb3RSVEVNUnJEODJiYlp5NGs2ZVphdGlUdUd5VFB0?= =?utf-8?B?T2x5dFhKLzJlWHlDR3JBbktEQXZWenArOVBKVWdmWXNHQTBBa0dJVzhIbXpZ?= =?utf-8?B?TEk4bGZtT1B3eUQ2VXZMTXZhWFdIUENlQ3hLdWhSTXhBNXRYSXVkLzN2K2Qr?= =?utf-8?B?akJoejFVQi85NExESkt1ZlZHbFZ4Q1VqR3VZZDFpYTBBcy8zNS9aUlpJSWVL?= =?utf-8?B?dXA0aTQyQjNjRjZzMm9SenpPVm1Yc09tR09yZDR3VE12eUdtMHpHbUliM0Zx?= =?utf-8?B?YlIwLytEZVBPeGkvZlhCSjRQeHpiN1h3U3I5UTYzNnN3OXMvWFFWTE9sZHk4?= =?utf-8?B?TThReW5ocmh0S3N4WU9lc0FyeHdka1ZhSFdYeGlQMkd2S0FRbEtvRzBYaE9p?= =?utf-8?B?S3hOK3Nia3RvTm1WdWZyK0NBZjF3PT0=?= 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)(1800799024)(36860700013)(376014)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 04:38:52.1942 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b1fddbf7-b55b-4fad-c2e8-08de597024d4 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: BN3PEPF0000B373.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8648 Hello Vincent, On 1/21/2026 10:30 PM, Vincent Guittot wrote: >>> If protect_slice() was true to begin with, we should do: >>> >>> if (protect_slice) >>> se->vprot = min_vruntime(se->vprot, se->deadline); >>> >>> This ensures that if our deadline has moved back, we only protect until >>> the new deadline and the scheduler can re-evaluate after that. If there >>> was an entity with a shorter slice at the beginning of the pick, the >>> "vprot" should still reflect the old value that was calculated using >>> "se->vruntime" at the time of the pick. >>> >> >> Regarding your suggestion, I have a concern. >> When a task's weight changes, I believe its "vprot" should also change >> accordingly. If we keep the original "vprot" unchanged, the task's >> actual runtime will not reach the expected "vprot". >> >> For example, if the weight decreases, the "vruntime" increases faster. >> If "vprot" is not updated, the task will hit the limit much earlier than >> expected in physical time. > > Ok but it's the safest way to stay in the min runnable slice limit so > you need to demonstrate that its lag will remain below. > Run to parity already goes close to this limit by not looking at a new > running entity at every tick so we need to be sure to not break this > rule. Wakeups will do a update_protect_slice() at the common ancestors for RUN_TO_PARITY but this is also a problem for cgroups where the current sched_entities can undergo a reweight at every tick. For Wang's specific case, the problem is "se->vprot" can expand if entity's weight goes down but update_protect_slice() does a min(se->vprot, se->vruntime + scale_delta_fair(min_slice, se)) which is capped by the original vprot. The reweight can end up with a case where: se->vprot < se->deadline < se->vruntime + scale_delta_fair(min_slice, se) (at time of pick) (after reweight) Ideally, we should redo set_protect_slice() with the same situation at the time of pick with adjusted vruntime, deadline, and considering the current set of tasks queued but it boils down to the same way we do "rel_deadline" today right? wakeup_preempt_fair() would have already updated the vprot based on the min_slice and since we do a scale_delta_fair(min_slice, se) in {set,update}_protect_slice(), it scaling it with the current entity's weight shouldn't be a problem I suppose. > >> >> Therefore, I made this modification to ensure the protection slice is >> valid. I would like to hear your thoughts on this. >> >> if (protect_slice) { >> se->vprot -= se->vruntime; >> se->vprot = div_s64(se->vprot * se->load.weight, weight); >> se->vprot += se->vruntime; >> >> se->vprot = min_vruntime(se->vprot, se->deadline); > > Why not use update_protect_slice() like when a new task with a shorter > slice is added ? Are you suggesting something like the following to keep protect_slice() updated at enqueue? diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index dc905b853c4b..c21fb039038b 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -6937,15 +6937,20 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, int flags) } for_each_sched_entity(se) { + struct sched_entity *curr; + cfs_rq = cfs_rq_of(se); + curr = cfs_rq->curr; update_load_avg(cfs_rq, se, UPDATE_TG); se_update_runnable(se); update_cfs_group(se); se->slice = slice; - if (se != cfs_rq->curr) + if (se != curr) min_vruntime_cb_propagate(&se->run_node, NULL); + if (curr && curr->on_rq) + update_protect_slice(cfs_rq, curr); slice = cfs_rq_min_slice(cfs_rq); cfs_rq->h_nr_runnable += h_nr_runnable; -- Thanks and Regards, Prateek