From: Peter Zijlstra <peterz@infradead.org>
To: David Laight <david.laight.linux@gmail.com>
Cc: K Prateek Nayak <kprateek.nayak@amd.com>,
Zhan Xusheng <zhanxusheng1024@gmail.com>,
Ingo Molnar <mingo@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Juri Lelli <juri.lelli@redhat.com>,
linux-kernel@vger.kernel.org,
Zhan Xusheng <zhanxusheng@xiaomi.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Valentin Schneider <vschneid@redhat.com>,
Ben Segall <bsegall@google.com>,
Steven Rostedt <rostedt@goodmis.org>,
Mel Gorman <mgorman@suse.de>
Subject: Re: [PATCH RESEND] sched/fair: Fix overflow in vruntime_eligible()
Date: Fri, 1 May 2026 15:43:07 +0200 [thread overview]
Message-ID: <20260501134307.GD1026330@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20260501140521.27be883d@pumpkin>
On Fri, May 01, 2026 at 02:05:21PM +0100, David Laight 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.
> >
> > 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.
>
> Older versions of gcc (maybe before 10?) generate a call to the full
> 128 bit multiply (_muldid3 ?) on mips64 - rather than just using the instruction
> that generates the high part of the product.
> The library function is now included but is slightly more complex because
> it does the high*low multiples as well.
>
> The same happens on sparc64 and the asm multiply code looks strange.
godbolt only has mips64 gcc-9.5 (no 8.1 which is the very oldest gcc we
support) and that doesn't seem to generate calls to library functions.
I don't particularly care about the quality of old compiler output, nor
do I really care for the performance aspect on these fringe
architectures. As long as it builds and isn't obviously broken, things
are good.
Using the gcc-8.5 toolchains from kernel.org (the oldest still supported
set) I see no library calls for MIPS64.
I do see them for Sparc64, but that actually has that library call
implemented.
Anyway, I'll throw it at the robots, see what if anything pops out.
> > 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;
>
> Seems strange that this is signed but the 64bit one is unsigned.
They both signed. __int128 is a signed type.
next prev parent reply other threads:[~2026-05-01 13:43 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-15 14:57 [PATCH] sched/fair: Fix overflow in vruntime_eligible() Zhan Xusheng
2026-04-28 14:49 ` [PATCH RESEND] " Zhan Xusheng
2026-04-28 16:17 ` K Prateek Nayak
2026-04-28 17:35 ` Peter Zijlstra
2026-04-29 5:03 ` K Prateek Nayak
2026-04-29 7:31 ` Zhan Xusheng
2026-05-01 10:40 ` Peter Zijlstra
2026-05-01 10:48 ` Peter Zijlstra
2026-05-01 13:05 ` David Laight
2026-05-01 13:43 ` Peter Zijlstra [this message]
2026-05-04 11:22 ` Peter Zijlstra
2026-05-04 13:16 ` Heiko Carstens
2026-05-04 14:57 ` Peter Zijlstra
2026-05-04 17:40 ` Stefan Schulze Frielinghaus
2026-05-05 10:31 ` Peter Zijlstra
2026-05-05 10:50 ` [tip: sched/urgent] " tip-bot2 for Zhan Xusheng
2026-05-05 14:13 ` tip-bot2 for Zhan Xusheng
2026-05-06 3:47 ` [PATCH RESEND] " Zhan Xusheng
2026-05-06 15:51 ` [tip: sched/urgent] " tip-bot2 for Zhan Xusheng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260501134307.GD1026330@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=bsegall@google.com \
--cc=david.laight.linux@gmail.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=zhanxusheng1024@gmail.com \
--cc=zhanxusheng@xiaomi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.