From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from PH0PR06CU001.outbound.protection.outlook.com (mail-westus3azon11011022.outbound.protection.outlook.com [40.107.208.22]) (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 C3B332C08B0 for ; Thu, 12 Feb 2026 07:43:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.107.208.22 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770882225; cv=fail; b=C73du5LeuiY3PdiBTDrZJOaQIcoSwnz9UkLCwS0QeeFDZn/F4c5eJWye8iKfDYVlzi51fQEtzdw9+R9caVsDfc0C3OrHtEBdZtlrb3ZwVWuRlRmiP/wK70H4RU/K6JKCJjudjJw/B+HdybGBIgRQ2UaClEPWx6eCmxp0nYYNlWw= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770882225; c=relaxed/simple; bh=5ntx9V8q6Largg1x8thXjQur/No9sIa7apT9FcmRqgY=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=AMpHW1qHlQUCdphwm4h58k+fAJgPDatIpDsRv2aeCUCieHHbLkCiderAJCBVZ7IEBmJiB+8OpCGKeV67ReA9WGR4RpAYoStuI2Z+HLbY+L33du9r+WujVtxAkPr5EDCeV23qnbqIrn0X9oP8wYS+V1T/v2EdnLooG2KPp7eIwT0= 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=Qi6CWhav; arc=fail smtp.client-ip=40.107.208.22 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="Qi6CWhav" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Agj3Hr6jXHbLLM+xXBZ9OT4tJdvELWsDZB6JmtzgHinc7LTtwfsoZ21HBFAz5nobOuwJ0OlRqKtrVFm6E4I9UtGxaWo91aiSJRbFuKUXST99CeKarD0SzD3+3hGvyYRbM+Vw1wte/zn3+QnOo+rbHpq4W6/Co5vLKLxLODU0qG0e0kwTSBbELnJwjebnyotKm81/ZIYMg8u145MuZq119tmSoC/SfJOygSJCBtsrcAi02+QbvBQal6JSt/j7DSSJBObMglcH5b4N9rayHv50MLfgVfZKrWyVocj5YHsZ3JQoJUmc3cGMIMXNIeBoXuP6hpLM6OitA6bgT1hXXlcPHA== 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=T3VslMiquDukC0D8ezcskSw7vZhTBVU74YYINCY1Ojo=; b=N/L0+TxfeEfZf4vtTk21rnRpiij9+6qllpf2st9oLVQHCKGmLTYOw+iUqWKwI3t2I2US49K111E354mPR8m2k59MBB7+5DFlURg5sFKK+8w++rAK/O0+5AORTNG/FEfBGyW4Fccax8yJESJmxt93sGXo4jkAbptx9TmVQdqwhmukqTzSxlZyfxJHRgYNF7uMbe7Az52dD/FZEzQNoc63eCPfTyvk51E6dL448TfsxBukDa2AgWSocsofxm1xgGKUiTDZRWt4bnAHnc8zT79LeFiLwFXZzubToAcvspXYofLC5PY1uloG0Dxx9ss7UqJmxFi8BrDd/1/oSonPZudacw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=infradead.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=T3VslMiquDukC0D8ezcskSw7vZhTBVU74YYINCY1Ojo=; b=Qi6CWhav5rgsddfzfKCixYzD24pDly5oLBf0tbEAjgRPPgIM0iMX4UAcuK6n+4kTkiK1xsM3CSUnKI6TDV3LiTZrLw6xETNDYj6fj6/KQE7cAyaDAGVh5OjH7p728DjrRz9HDKYDWn6sck8L2fPOf2cumpaOME79CZbxRWr+EE0= Received: from PH8P221CA0061.NAMP221.PROD.OUTLOOK.COM (2603:10b6:510:349::17) by DM4PR12MB7573.namprd12.prod.outlook.com (2603:10b6:8:10f::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9611.10; Thu, 12 Feb 2026 07:43:35 +0000 Received: from SN1PEPF00036F41.namprd05.prod.outlook.com (2603:10b6:510:349:cafe::8e) by PH8P221CA0061.outlook.office365.com (2603:10b6:510:349::17) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9611.11 via Frontend Transport; Thu, 12 Feb 2026 07:43:42 +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=satlexmb08.amd.com; pr=C Received: from satlexmb08.amd.com (165.204.84.17) by SN1PEPF00036F41.mail.protection.outlook.com (10.167.248.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9611.8 via Frontend Transport; Thu, 12 Feb 2026 07:43:34 +0000 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 12 Feb 2026 01:43:34 -0600 Received: from [10.136.42.168] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Thu, 12 Feb 2026 01:43:31 -0600 Message-ID: <58c6c115-f544-4c51-990c-a3ad2fbf701a@amd.com> Date: Thu, 12 Feb 2026 13:13:30 +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 0/4] sched: Various reweight_entity() fixes To: Peter Zijlstra , Vincent Guittot CC: Doug Smythies , , , , , , , , , , , References: <20260203111134.GL1282955@noisy.programming.kicks-ass.net> <38ef3462-4c4e-4f40-8d63-84dd71cbd043@amd.com> <20260209154718.GW1282955@noisy.programming.kicks-ass.net> <002501dc9b16$442a7050$cc7f50f0$@telus.net> <20260211090144.GY1282955@noisy.programming.kicks-ass.net> <20260211104833.GH1395416@noisy.programming.kicks-ass.net> <20260211162825.GZ1282955@noisy.programming.kicks-ass.net> Content-Language: en-US From: K Prateek Nayak In-Reply-To: <20260211162825.GZ1282955@noisy.programming.kicks-ass.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SN1PEPF00036F41:EE_|DM4PR12MB7573:EE_ X-MS-Office365-Filtering-Correlation-Id: 76f6bfe4-3c71-4c39-e0e4-08de6a0a6d50 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|376014|82310400026|36860700013|1800799024; X-Microsoft-Antispam-Message-Info: =?utf-8?B?Zm1DSXYrejhLbTVyd2doK2IyREorLzJHdFFmK2VMOTlIMzdxbHIvL2tPNWxS?= =?utf-8?B?dkFndWpGZGcvbGdTdnpSZUNMcE5UYXc0citXMy96dWZzYUgweDIwczRtWEhS?= =?utf-8?B?bFgwcXlJOUZnY3VINkJKdkI1SzNrWlN2Vk5PUlRnSndIbE4yNndBR3c2ZVVm?= =?utf-8?B?a2hObTJBandydjZpLzJGL0lINUltcksrcU1taWFwNkpmaWIxNTZJdXh4Q3ht?= =?utf-8?B?Q1JOaHpROGVDc3hJSVA5NFpxRUJ1a0szSDRoL0pXYzNWQ1RuV2pIb0FqZjRU?= =?utf-8?B?eVhNMVJvN3hMbHZDd1BLeWZJeUxxaXBkeUd4QzFsK2xsZDQwMWFWRHU1cjBz?= =?utf-8?B?NG8vNGpwbEFsVEx1L21pWTIzUXVHbGFmdVZDSEVuSXhaeGVsKyt6TklZSm1F?= =?utf-8?B?ZjN3MWprdm9VamJNRWdXZ0tzbmd3QU1qUEpiSnpoUnd2ektNSDdlZGM5bzc2?= =?utf-8?B?RjZsL01ZSVB1TnJhL2RJSFRqZmVKWGtjQlBYUExIS09nb3pWN2FSMU5CWjY4?= =?utf-8?B?MitGUDE3MlBwbzdybExXdmlqR0ZvNklObFJwb1BlMzBEeVVWK1lsWEtQVWs3?= =?utf-8?B?a01WY3V2bGlNYUdHNWNLV3l0anlXY2tBSGZDWGR3L1plc2x2ejZKL3B4OTBy?= =?utf-8?B?QS9GSHRVQzlkM0szb0JLLzdYbGNibVVFeHUxVXQ5K1NSS1pvUkpCZjI0dGo4?= =?utf-8?B?cUZqeFNubkZ4VHZNZDViaG5DMHdxWGdnRkJTWEVEb3RYbm9DVDJtRHBNMlc1?= =?utf-8?B?SXhtTC9BNUlWUDNxUURMSXQzZGhyRFBnSjRsZmxhSE1qcDhWMDdkdHNXNytV?= =?utf-8?B?RE5YVDNGbGg5cmp2QUdZalVXQXY3VmlKcG5xT0dFaXVKNVdZbHgzTmt0MlNM?= =?utf-8?B?SXlIbi93SlA5NUxnYU4rSnE3YTZZYnhjN05VOEo5bVBXZXZ5a25CZkhhVDNG?= =?utf-8?B?VFludkNoeEJ6TWtoWFVuUmo0QVVxa1U2RGluQUdicnNRZkpzSTYyVmZGbmNu?= =?utf-8?B?ZjhBamxzSHFsUVlucVkrWGtCblRmbkg0ekc3Y3Z6clFnZHByQjBPeWF4TTUv?= =?utf-8?B?MUx2azdnUlB2dXB6Q3c3MUpybjV3YzVXdHlCREhqVmlHQ3RVa283eDAyaE9w?= =?utf-8?B?QXE2aURVODNpR0h1Tk9DTnBJR1p1TnlzTkFkMXRzTGZnR1Y1eml6VDdRaEtR?= =?utf-8?B?Qk5TeE4yUlZZSjJJcGZadTdJbWVyYm52V1JhdFM0MkRBcW5wNXRiWTB2anFj?= =?utf-8?B?ZE1DMnpJSmVkU2dJSTVJYVc0eng4dkNnK1dMT1MwdmxabmJsMGRQMGRoOFNw?= =?utf-8?B?YmtlTnVUeEwxeWNjOS9mNzUwSnZLQW1yaktPem9Ia1RCYmNlUGthNDZ1RGRG?= =?utf-8?B?NlBuNHpEMml1bjNvdnIyajVNcEZsSGxNS0crZnRpamFZa3FVcGRValoxamJQ?= =?utf-8?B?UlVzQUYrRGVoQ3cxekNaN2haY3FFYVBZMDN0dTA2WUlXTHo0R0pMQ2E0MEVp?= =?utf-8?B?dTBZWVVCdEE0bFFCNjF0ckpvVENoSGhKUDNnSXVyYXlIS005NTVMUXVqVENR?= =?utf-8?B?L21YKzJDOHYzN0JvUlhkQnFnYmdaTUh3M2pNNWVLYXNsOVFjT0I0dnhHVzlq?= =?utf-8?B?d0dZejd3KzUwSmpUQ1piSHdxVVZZQ2M4L2lVWFNlRnhIMTVpaVo0a3Q0Nnda?= =?utf-8?B?KzVpSnczK05XZ1VYYjBWNnJ3TEdoZnAxRXowRFdobVBSdVk3eStNQUlKc293?= =?utf-8?B?M1NXc0hQVDF3am1renk4VGw5TzVYdE9HY1NGdWpFc0xSUk4zUXBIMzIyWkU5?= =?utf-8?B?UFFRcUp2SFdLUExGaVQxUDQwVTZHZ0dNY0VHQXRIQ1VCeUxZQmdjb3hHMFBM?= =?utf-8?B?RGtHVndGMlFrZnNyNWZMSmNPdENqMHNGdTkzR05ZVzVJbldjanVhWWp6NHZl?= =?utf-8?B?eHhoWWtaWXBQcXlycmV0RGR6SDFoZnlERXRCYnZRd01SZHV3ck85N21KK0xj?= =?utf-8?B?SnNYODdhTXFMZUppTWptdjI3UC92WVU4cWlYMVN6MXBRSFFnWld6YXhla09s?= =?utf-8?B?OTljYUJPUks5MVZ3VmVXOU5xSXFQRUJoWFlSWThRUEZ0M1duVXdKUTVua0Zs?= =?utf-8?B?VmNBbWYreUZiVURlZUxJSk51Q2VqbWxXNStmUzBoQnhQR2lpM3AvNmMxYzZD?= =?utf-8?B?TUc4WjBObmNxWHQzZy9Fc3c4K0YrVFVrOEFZemJPSWNmN1dpV1JrVWh5OU9H?= =?utf-8?B?UjVpa29tb3FUVXdxcFRyemN1WUFBPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(7416014)(376014)(82310400026)(36860700013)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: XDxj65Uaq3SlqDsPwupzLJ+G+qqXJs5tIb3sWJ4gCSCREUFBhOwIPSeqeiiFgjrLzaSk/84XUaxmKz6UQFSeIg6jQ4eVA6SQ0+aF7oXJRT9Wf6hhOG1tJfq9OGftP91yWX/5ZPo/VCbzkwzogOQZsFWkT1nZzLx8P8JNBhSJ4hlRJXFFWyLn/UQSnQJxGBal4cvLweQOxN32BXLszuCVKrLjXBqWlfkJoecGMmMRz1LFlrXOgjnwDi4tYGzGFoe9cS8xBYdX17DFeTDC+Ktr68qzz1IT63tNnpOn/QLj6l3JZiY7W6EBc2Z4kslChYgkpKsTRnRutOMhJjZSg7yu6C/ifbw04aCVBXdoJQXm4wPZpW3bjqQ+ScXkAMmZA3d7Ay4xL8a0BpBCxL+V5E+0IauTU43doyrWN3C6QU7iPpIS/7bkNMW32lmtvjKTpPqd X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Feb 2026 07:43:34.8800 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 76f6bfe4-3c71-4c39-e0e4-08de6a0a6d50 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=[satlexmb08.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SN1PEPF00036F41.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB7573 Hello Peter, On 2/11/2026 9:58 PM, Peter Zijlstra wrote: > On Wed, Feb 11, 2026 at 12:15:48PM +0100, Vincent Guittot wrote: > >> Regarding the use of calc_delta_fair() in update_entity_lag(), we use >> calc_delta_fair() for updating vruntime, deadline, vprot and vlag and >> I wonder how this diff of granularity compared to avg_vruntime can be >> an issue for sched_entity with a small weight > > It will effectively inflate their weight. > > The below seems to 'work' -- it builds, boots and builds a kernel. > > We could perhaps look at doing that reciprocal thing on unsigned long, > but meh. So I was testing peterz:sched/core at commit 84230c0ac1cf ("sched/fair: Use full weight to __calc_delta()") and it still crashes for the exorbitantly large copies of "yes" running on 6 cores. Here is what I've found out from today's crash on dumping the offending cfs_rq: ... Enqueue cfs_rq: depth(1) weight(2144337920) nr_queued(2045) sum_w_vruntime(18343811230990336) sum_weight(2144337920) zero_vruntime(18337852274) sum_shift(0) avg_vruntime(18337852274) Dequeue cfs_rq: depth(1) weight(2144337920) nr_queued(2045) sum_w_vruntime(1303379968) sum_weight(2143289344) zero_vruntime(18354971669) sum_shift(0) avg_vruntime(18354971669) Enqueue cfs_rq: depth(1) weight(2152726528) nr_queued(2053) sum_w_vruntime(-31233567079006208) sum_weight(2152726528) zero_vruntime(18360916028) sum_shift(0) avg_vruntime(18360916028) Dequeue cfs_rq: depth(1) weight(2152726528) nr_queued(2053) sum_w_vruntime(-25773095996358656) sum_weight(2151677952) zero_vruntime(18366916795) sum_shift(0) avg_vruntime(18366916795) Enqueue cfs_rq: depth(1) weight(2152726528) nr_queued(2053) sum_w_vruntime(-195993505307295744) sum_weight(2152726528) zero_vruntime(18437453448) sum_shift(0) avg_vruntime(18437453448) Dequeue cfs_rq: depth(1) weight(2152726528) nr_queued(2053) sum_w_vruntime(-355777007188967424) sum_weight(2151677952) zero_vruntime(18520289238) sum_shift(0) avg_vruntime(18520289238) Enqueue cfs_rq: depth(1) weight(2152726528) nr_queued(2053) sum_w_vruntime(-1523774576650092544) sum_weight(2152726528) zero_vruntime(19054245803) sum_shift(0) avg_vruntime(19054245803) Dequeue cfs_rq: depth(1) weight(2152726528) nr_queued(2053) sum_w_vruntime(-3015239905359953920) sum_weight(2151677952) zero_vruntime(19756286051) sum_shift(0) avg_vruntime(19756286051) # I'm suspecting something goes sideways at this point looking at # the big jump that comes after in avg_vruntime() # "6222537296247259136" has bit 63 set so could it be a wraparound # in sum_w_vruntime? Enqueue cfs_rq: depth(1) weight(2152726528) nr_queued(2053) sum_w_vruntime(6222537296247259136) sum_weight(2152726528) zero_vruntime(24024889432) sum_shift(0) avg_vruntime(24024889432) Dequeue cfs_rq: depth(1) weight(2152726528) nr_queued(2053) sum_w_vruntime(-5928597400870453248) sum_weight(2151677952) zero_vruntime(21110281285) sum_shift(0) avg_vruntime(21110281285) cfs_rq of failed pick: cfs_rq: depth(0) weight(2176843776) nr_queued(2076) sum_w_vruntime(-90907067772043264) sum_weight(2175795200) zero_vruntime(26921355273) se: weight(1048576) vruntime(843832351) slice(2800000) deadline(846630448) curr?(1) task?(1) delayed?(0) se_depth(1) se: weight(1048576) vruntime(839841550) slice(2800000) deadline(842635020) curr?(0) task?(1) delayed?(0) se_depth(1) ... # Many entities have weight 1048576, and and vruntime around ~850,000 .... se: weight(1048576) vruntime(843832916) slice(2800000) deadline(846629681) curr?(0) task?(1) delayed?(0) se_depth(1) se: weight(1048576) vruntime(843833563) slice(2800000) deadline(846630939) curr?(0) task?(1) delayed?(0) se_depth(1) se: weight(1048576) vruntime(843840684) slice(2800000) deadline(846633192) curr?(0) task?(1) delayed?(0) se_depth(1) se: weight(1048576) vruntime(18344670326) slice(2800000) deadline(18347465508) curr?(0) task?(1) delayed?(0) se_depth(1) se: weight(1048576) vruntime(18344679852) slice(2800000) deadline(18347475866) curr?(0) task?(1) delayed?(0) se_depth(1) se: weight(1048576) vruntime(18344682061) slice(2800000) deadline(18347477764) curr?(0) task?(1) delayed?(0) se_depth(1) ... # Many entities have weight 1048576, and and vruntime around ~18,344,682,061 I'm running with CONFIG_HZ=250. In vruntime_eligible() we have for curr: entity_key(curr) = -26077522922LL weight = 1048576UL For the cfs_rq we get: avg = sum_w_runtime + (entity_key * weight) = -118251332447502336LL load = sum_weight + weight = 2176843776UL But on the way to check eligibility we compute: entity_key * load = -56766693466253033472 (in python) entity_key * load = -1426461245124378624LL (in C) vruntime_eligible() returns false always as a result of the overflow and we land in a pickle. Not sure if sum_w_vruntime itself can suffer from a wrap around that leads to all this. Parsing the stats based on the dump in Python gives me: Total weight: 2176843776 (checks out) Total weighted vruntime: 3145101113938673664 Avg (floating point): 1444798725.849711 Avg (signed 64-bit): 1444798725 Avg (unsigned 64-bit): 1444798725 which is a bit far off from the dumped stats of cfs_rq. -- Thanks and Regards, Prateek