[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aUDHE/SYbnKNVHMU@xsang-OptiPlex-9020>
Date: Tue, 16 Dec 2025 10:42:27 +0800
From: Oliver Sang <oliver.sang@...el.com>
To: Peter Zijlstra <peterz@...radead.org>
CC: Fernand Sieber <sieberf@...zon.com>, <oe-lkp@...ts.linux.dev>,
<lkp@...el.com>, <linux-kernel@...r.kernel.org>, <aubrey.li@...ux.intel.com>,
<yu.c.chen@...el.com>, Ingo Molnar <mingo@...nel.org>,
<oliver.sang@...el.com>
Subject: Re: [linus:master] [sched/fair] 79104becf4:
stress-ng.resched.ops_per_sec 44.6% regression
hi, Peter Zijlstra,
On Fri, Dec 12, 2025 at 11:12:44AM +0100, Peter Zijlstra wrote:
> On Thu, Dec 11, 2025 at 10:21:15PM +0800, kernel test robot wrote:
> >
> >
> > Hello,
> >
> > kernel test robot noticed a 44.6% regression of stress-ng.resched.ops_per_sec on:
> >
> >
> > commit: 79104becf42baeeb4a3f2b106f954b9fc7c10a3c ("sched/fair: Forfeit vruntime on yield")
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
> After nearly 2 decades of telling people that using yield() is UB
> (except in the Real-Time cases where it is well defined), I'm >.< close
> to not caring about this.
>
> IIRC this benchmark is literally something like running yield() in a
> loop, so boohoo. I'll look when there's a real workload that has a
> problem.
got it. we won't report performance impact of this commit from micro benchmark
tests again.
>
> > [still regression on linus/master cfd4039213e7b5a828c5b78e1b5235cac91af53d]
> > [still regression on linux-next/master 82bcd04d124a4d84580ea4a8ba6b120db5f512e7]
>
> What's with the still? AFAIK this is the first report of this.
our report is based on bisect results. for mainline report, we do a further
check upon latest linus/master and linux-next/master. we only report when the
regression still exists there. so above 2 lines is just for information.
Powered by blists - more mailing lists