From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 E3ACD38F646 for ; Fri, 1 May 2026 10:48:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777632500; cv=none; b=tLIQYQeGl/3qOSKQQfh/wIbwn9LL/J/GByOI6IUQUiSaYJBZiEmHRpdDcH31FLzo/bNzD22D8BdaDTSDsw6y6Q0ggbhTns+Bz2F0ZRqYkbI5MOGXiFsv3BJmyiZhcIQ5JrEgQ7C3qYQ4dwZXZHigs/9aSD/U4YsvJ71N/MWTsmE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777632500; c=relaxed/simple; bh=SksUGKTTKdKtd6D4d1GVxBpW71LDCuZ5WIQO3NZIqdM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lxeWnvK0zRFsz8GaKyLL0YOOMvX01BAL5PExWqayJ/WS8uAHlQT6w+A/8/Vh/p40KTSXhKXMdiRWbwBwULocr6uvf6Y8VqPgvjx0MIhiK80wBOYQM45lxXqfkJl9Fu/VDbTsHGxEwAV3L+tuvHHTdZeG1AWJiQFGcWuOJKALjzA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=jeNtofJs; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="jeNtofJs" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=mfR6HlakFmmJ+PxZY2PXoAENa7kFcn6ubHoo8J5xl2s=; b=jeNtofJszhlxr83hz4sD7J2sz8 WniGsr8DzZFU9hCh91ZG1tuK6bj7F9ahci8wk7bUBikUpS+K99u2H5XKJhM31GqfU3V8xYRx+SW5T UUnsGpW5niponG/HbHUZWm5CL7J7acCt0jbmfQbG5HMpHsSwhWM+Xk4ormwuDGpAEHwYKeYADX4Dm /SCC0r6tb/Qpw3H8yGWY7dlA13o38dolm5m8L8tGVhk6U5ulZvJ/sV22er+8ZoJKE7GrZm22DmoU5 GBSytEidba6t5tBcQ88RxspUrWYZzQ1lKErxOw5X1Mt3wCo4YxdepW9SfXq/eYidb3DqVjz68c/eM H9MTGm7Q==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1wIlPj-00000008h3y-0cAD; Fri, 01 May 2026 10:48:07 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 313333008E2; Fri, 01 May 2026 12:48:05 +0200 (CEST) Date: Fri, 1 May 2026 12:48:05 +0200 From: Peter Zijlstra To: K Prateek Nayak Cc: Zhan Xusheng , Ingo Molnar , Vincent Guittot , Juri Lelli , linux-kernel@vger.kernel.org, Zhan Xusheng , Dietmar Eggemann , Valentin Schneider , Ben Segall , Steven Rostedt , Mel Gorman Subject: Re: [PATCH RESEND] sched/fair: Fix overflow in vruntime_eligible() Message-ID: <20260501104805.GM3102924@noisy.programming.kicks-ass.net> References: <20260415145742.10359-1-zhanxusheng@xiaomi.com> <20260428144951.121765-1-zhanxusheng@xiaomi.com> <57e94d7e-b8fb-49bc-a914-8a7401e43af3@amd.com> <20260428173521.GK3126523@noisy.programming.kicks-ass.net> <4870ea19-78d4-44b2-9f18-14c3f8782726@amd.com> <20260501104006.GA3102624@noisy.programming.kicks-ass.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260501104006.GA3102624@noisy.programming.kicks-ass.net> On Fri, May 01, 2026 at 12:40:06PM +0200, Peter Zijlstra wrote: > Anyway, I had a poke around with godbolt, and the below seems to > generate the best code for things like x86_64 and arm64. https://godbolt.org/z/T389jd7bn > Specifically, the __builtin_mul_overflow() already has to compute the > 128 bit product anyway for most architectures, so using that directly > then leads to saner asm and easier to understand code. > > AFAICT HPPA64 is the only 64bit architecture that doesn't implement > __int128 and will thus be demoted to doing what we do on 32bit. > > Now all I need to do is write a coherent Changelog to go with it ... > *sigh* > > --- > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 728965851842..214fe9d99834 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -904,7 +904,7 @@ static int vruntime_eligible(struct cfs_rq *cfs_rq, u64 vruntime) > load += weight; > } > > - return avg >= vruntime_op(vruntime, "-", cfs_rq->zero_vruntime) * load; > + return avg >= (sched_double_long_t)vruntime_op(vruntime, "-", cfs_rq->zero_vruntime) * load; > } > > int entity_eligible(struct cfs_rq *cfs_rq, struct sched_entity *se) > diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h > index 9f63b15d309d..f15f4468efe5 100644 > --- a/kernel/sched/sched.h > +++ b/kernel/sched/sched.h > @@ -146,7 +146,7 @@ extern struct list_head asym_cap_list; > * Really only required when CONFIG_FAIR_GROUP_SCHED=y is also set, but to > * increase coverage and consistency always enable it on 64-bit platforms. > */ > -#ifdef CONFIG_64BIT > +#if defined(CONFIG_64BIT) && defined(__SIZEOF_INT128__) > # define NICE_0_LOAD_SHIFT (SCHED_FIXEDPOINT_SHIFT + SCHED_FIXEDPOINT_SHIFT) > # define scale_load(w) ((w) << SCHED_FIXEDPOINT_SHIFT) > # define scale_load_down(w) \ > @@ -157,10 +157,12 @@ extern struct list_head asym_cap_list; > __w = max(2UL, __w >> SCHED_FIXEDPOINT_SHIFT); \ > __w; \ > }) > +typedef __int128 sched_double_long_t; > #else > # define NICE_0_LOAD_SHIFT (SCHED_FIXEDPOINT_SHIFT) > # define scale_load(w) (w) > # define scale_load_down(w) (w) > +typedef s64 sched_double_long_t; > #endif > > /*