linux-kernel - Re: [PATCH] sched/fair: Disable scheduler feature NEXT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <2a52aaea-b13d-40e7-98f7-266f761dd634@arm.com>
Date: Tue, 20 Jan 2026 11:45:50 +0000
From: Ryan Roberts <ryan.roberts@....com>
To: Mel Gorman <mgorman@...hsingularity.net>,
 Peter Zijlstra <peterz@...radead.org>
Cc: Ingo Molnar <mingo@...hat.com>,
 Madadi Vineeth Reddy <vineethr@...ux.ibm.com>,
 Juri Lelli <juri.lelli@...hat.com>,
 Dietmar Eggemann <dietmar.eggemann@....com>,
 Valentin Schneider <vschneid@...hat.com>, Chris Mason <clm@...a.com>,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched/fair: Disable scheduler feature NEXT_BUDDY

On 20/01/2026 11:33, Mel Gorman wrote:
> NEXT_BUDDY was disabled with the introduction of EEVDF and enabled again
> after NEXT_BUDDY was rewritten for EEVDF by commit e837456fdca8 ("sched/fair:
> Reimplement NEXT_BUDDY to align with EEVDF goals"). It was not expected
> that this would be a universal win without a crystal ball instruction
> but the reported regressions are a concern [1][2] even if gains were
> also reported. Specifically;
> 
> o mysql with client/server running on different servers regresses
> o specjbb reports lower peak metrics
> o daytrader regresses
> 
> The mysql is realistic and a concern. It needs to be confirmed if
> specjbb is simply shifting the point where peak performance is measured
> but still a concern. daytrader is considered to be representative of a
> real workload.
> 
> Access to test machines is currently problematic for verifying any fix to
> this problem. Disable NEXT_BUDDY for now by default until the root causes
> are addressed.
> 
> Link: https://lore.kernel.org/lkml/4b96909a-f1ac-49eb-b814-97b8adda6229@arm.com [1]
> Link: https://lore.kernel.org/lkml/ec3ea66f-3a0d-4b5a-ab36-ce778f159b5b@linux.ibm.com [2]
> Signed-off-by: Mel Gorman <mgorman@...hsingularity.net>

Thanks for posting this, Mel. And sorry I've been slow getting back to you in
the other thread. It's still on my list to respond properly and get the data
that you and Peter were requesting, but I've been spinning plates this week.
Hopefully I can get to it next week.

In the mean time I'll request a full benchmark run with this patch on top of
-rc6 to confirm our observed regressions go away (although I think we are pretty
confident they will).

Thanks,
Ryan

> ---
>  kernel/sched/features.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/sched/features.h b/kernel/sched/features.h
> index 980d92bab8ab..136a6584be79 100644
> --- a/kernel/sched/features.h
> +++ b/kernel/sched/features.h
> @@ -29,7 +29,7 @@ SCHED_FEAT(PREEMPT_SHORT, true)
>   * wakeup-preemption), since its likely going to consume data we
>   * touched, increases cache locality.
>   */
> -SCHED_FEAT(NEXT_BUDDY, true)
> +SCHED_FEAT(NEXT_BUDDY, false)
>  
>  /*
>   * Allow completely ignoring cfs_rq->next; which can be set from various