From nobody Fri Jun 12 12:47:03 2026 Received: from fhigh-a4-smtp.messagingengine.com (fhigh-a4-smtp.messagingengine.com [103.168.172.155]) (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 0D1C9282F3A for ; Thu, 14 May 2026 20:26:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.155 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778790394; cv=none; b=cJSxJCQMC+lRn0bQ6dCzEL5nZHqoH8MfNenh17z3R7onQqVXVgkTyjz2ypJaxoBaoL+YMJvAKDUH0kSRrmjkgSDgDdW2khB+Mhj06TbjsnM08KY5V3qPr/fQn26hffkIJVdsSzZ/kqhloG7mepke7/misdx9DXxjd85dURDxvQo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778790394; c=relaxed/simple; bh=xIwLWMb6rdm0f7nv1rkEZdDhY+8M57kpRjsEOE/kHUs=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=UExMOlKytrw+cSJbJyor93fLNXSelXn2VUYUT6aqDrfYefZwO3dfYqXNsD3NokVKy64beDuXCKAy1L9N9uM5metZI8L5sMDdOnQXYzQxO8l+PYMoWCsMW7eZfFHWikzYipVZFbErtW1wL2hUFZgTFrretvpouL7hGsHpSPeTa8g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=fluxnic.net; spf=pass smtp.mailfrom=fluxnic.net; dkim=pass (2048-bit key) header.d=fluxnic.net header.i=@fluxnic.net header.b=QbUsa7io; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=pt/fR4oK; arc=none smtp.client-ip=103.168.172.155 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=fluxnic.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=fluxnic.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=fluxnic.net header.i=@fluxnic.net header.b="QbUsa7io"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="pt/fR4oK" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfhigh.phl.internal (Postfix) with ESMTP id 45B6B14000A2; Thu, 14 May 2026 16:26:32 -0400 (EDT) Received: from phl-frontend-01 ([10.202.2.160]) by phl-compute-04.internal (MEProxy); Thu, 14 May 2026 16:26:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fluxnic.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:subject:subject:to :to; s=fm3; t=1778790392; x=1778876792; bh=aUDmEr0vyYjNueSEI9rIw CsfvVbKrMAsGqgOl22D85Q=; b=QbUsa7iowvAMVXu6KYF4Q83M/TTgcGBdY7lwm GoQUFPhSwsQk+hdXqjD1pYT576Ayr0GSiMJ92bJzErtHnMsdElud99HXi8W7GKFr 8P5j7z5TbLkhiT2pVsM3pVAcKobW7dUhLeRZft6ENdymWG6eh9T0vkiqHpqcRN+O CWSV7sizkJq7lxqiARf9PkDGpUtK4N41KLC59cjVuc6WAvec0Z8Uxc0hqA1tJyAs xDb9dFfY44C407sWAvUWfRkWoreUdvPAJGF1L1+stSxCWPevvuJKKJRbKjHyijsH 9sUtRzThkCdKrksyztZ+RpbcFdb20WjSvWfo8cyC4yeHubBhQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:message-id:mime-version:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1778790392; x=1778876792; bh=aUDmEr0vyYjNueSEI9rIwCsfvVbKrMAsGqg Ol22D85Q=; b=pt/fR4oKWUPJYGV+/qW8e+wUSh9jUEi3GDzMOsME2Ox6I60Wg+Z Nu945Ib3A1NIAHHwrRxcoMW42+HguahQEWlRNBQCgsLHjlR9ZkD35n5RyobeMtXJ XIfNxlG8q6pVZKFGMvTJW36vbeFpEreCfUTjBJg1YDsWE22eOFhLQEhXutR9DQHF nnxJak0NIL7MAJ3ifs5AwNlXaY/UKHe61+5NhcoCh5QZKWheresXJYsv0Gp61ump GRbDvfRrW6vpzllC/CVeCfMYznR0aH3qjCqdNLYVfdRlo6KSmR9eC4Q7ZE4gj1rJ JQ5KLfFwYg9/gE2fpO1aORjRkbsRAApBItg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdduvdekgeejucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhephffvvefufffkofgggfestdekredtredttdenucfhrhhomheppfhitgholhgrshcu rfhithhrvgcuoehnihgtohesfhhluhignhhitgdrnhgvtheqnecuggftrfgrthhtvghrnh ephefhfeetueeiteeigfffieelveethfduleegheelteehudetuedvjeffffdvhfevnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepnhhitghose hflhhugihnihgtrdhnvghtpdhnsggprhgtphhtthhopedufedpmhhouggvpehsmhhtphho uhhtpdhrtghpthhtohepkhhprhgrthgvvghkrdhnrgihrghksegrmhgurdgtohhmpdhrtg hpthhtohepughivghtmhgrrhdrvghgghgvmhgrnhhnsegrrhhmrdgtohhmpdhrtghpthht ohepuggrvhhiugdrlhgrihhghhhtrdhlihhnuhigsehgmhgrihhlrdgtohhmpdhrtghpth htoheprhhoshhtvgguthesghhoohgumhhishdrohhrghdprhgtphhtthhopegsshgvghgr lhhlsehgohhoghhlvgdrtghomhdprhgtphhtthhopeiihhgvnhhgiihutghhvghngheshh hurgifvghirdgtohhmpdhrtghpthhtohepphgvthgvrhiisehinhhfrhgruggvrggurdho rhhgpdhrtghpthhtohepvhhinhgtvghnthdrghhuihhtthhotheslhhinhgrrhhordhorh hgpdhrtghpthhtohepjhhurhhirdhlvghllhhisehrvgguhhgrthdrtghomh X-ME-Proxy: Feedback-ID: i58514971:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 14 May 2026 16:26:30 -0400 (EDT) Received: from xanadu.lan (_gateway [192.168.1.1]) by yoda.fluxnic.net (Postfix) with ESMTPSA id EDED01635A4A; Thu, 14 May 2026 16:26:29 -0400 (EDT) From: Nicolas Pitre To: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot Cc: Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , Zheng Zucheng , David Laight , linux-kernel@vger.kernel.org Subject: [PATCH] sched/cputime: Drop now-stale mul_u64_u64_div_u64() over-approximation guard Date: Thu, 14 May 2026 16:26:29 -0400 Message-ID: <20260514202629.673539-1-nico@fluxnic.net> X-Mailer: git-send-email 2.54.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Commit 77baa5bafcbe ("sched/cputime: Fix mul_u64_u64_div_u64() precision for cputime") added a clamp in cputime_adjust(): if (unlikely(stime > rtime)) stime =3D rtime; The justification was that mul_u64_u64_div_u64() could over-approximate on some architectures (notably arm64 and the old 32-bit fallback), so the mathematically impossible stime > rtime was nevertheless reachable and would underflow utime =3D rtime - stime. That premise no longer holds. Commit b29a62d87cc0 ("mul_u64_u64_div_u64: make it precise always") replaced the fallback implementation with an exact 128-bit long division, and the x86_64 inline asm already produced exact results. The helper now returns the mathematically correct floor(a*b/d) on every architecture, so stime <=3D rtime is guaranteed by stime <=3D stime + utime and the clamp is dead code. Remove it along with its stale comment. Signed-off-by: Nicolas Pitre --- kernel/sched/cputime.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c index fbf31db0d2f3..6e85023a81ff 100644 --- a/kernel/sched/cputime.c +++ b/kernel/sched/cputime.c @@ -587,12 +587,6 @@ void cputime_adjust(struct task_cputime *curr, struct = prev_cputime *prev, } =20 stime =3D mul_u64_u64_div_u64(stime, rtime, stime + utime); - /* - * Because mul_u64_u64_div_u64() can approximate on some - * achitectures; enforce the constraint that: a*b/(b+c) <=3D a. - */ - if (unlikely(stime > rtime)) - stime =3D rtime; =20 update: /* --=20 2.54.0