public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Ryan Roberts <ryan.roberts@arm.com>,
	Mel Gorman <mgorman@techsingularity.net>,
	Ingo Molnar <mingo@redhat.com>,
	Madadi Vineeth Reddy <vineethr@linux.ibm.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Valentin Schneider <vschneid@redhat.com>,
	Chris Mason <clm@meta.com>,
	linux-kernel@vger.kernel.org, Christian.Loehle@arm.com
Subject: Re: [PATCH] sched/fair: Disable scheduler feature NEXT_BUDDY
Date: Fri, 23 Jan 2026 11:09:15 +0100	[thread overview]
Message-ID: <20260123100915.GL171111@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <CAKfTPtBp6p+JC1J-oKXT6eLY41M71bhofq=zpLCQFGsVXEEgyg@mail.gmail.com>

On Fri, Jan 23, 2026 at 11:04:20AM +0100, Vincent Guittot wrote:
> On Fri, 23 Jan 2026 at 10:53, Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Thu, Jan 22, 2026 at 06:34:28PM +0100, Vincent Guittot wrote:
> >
> > > The new NEXT_BUDDY implementation is doing more than setting a buddy;
> > > it also breaks the run to parity mechanism by always setting next
> > > buddy during wakeup_preempt_fair() even if there is no relation
> > > between the 2 tasks and PICK_BUDDY bypasses protections
> > >
> > > In addition to disable NEXT_BUDDY, i suggest to also revert the force
> > > preemption section below which also breaks run_to_parity by doing an
> > > assumption whereas WF_SYNC is normally there for such purpose
> > >
> > > -- a/kernel/sched/fair.c
> > > +++ b/kernel/sched/fair.c
> > > @@ -8822,16 +8822,6 @@ static void wakeup_preempt_fair(struct rq *rq,
> > > struct task_struct *p, int wake_f
> > >         if ((wake_flags & WF_FORK) || pse->sched_delayed)
> > >                 return;
> > >
> > > -       /*
> > > -        * If @p potentially is completing work required by current then
> > > -        * consider preemption.
> > > -        *
> > > -        * Reschedule if waker is no longer eligible. */
> > > -       if (in_task() && !entity_eligible(cfs_rq, se)) {
> > > -               preempt_action = PREEMPT_WAKEUP_RESCHED;
> > > -               goto preempt;
> > > -       }
> > > -
> > >         /* Prefer picking wakee soon if appropriate. */
> > >         if (sched_feat(NEXT_BUDDY) &&
> > >             set_preempt_buddy(cfs_rq, wake_flags, pse, se)) {
> > >
> > > This largely increases the number of resched and preemption because a
> > > task becomes quickly "ineligible": We update our internal vruntime
> > > periodically and before the task exhausted its slice.
> >
> > Hmm, fair enough. Do I munge that into Mel's patch, or should I create a
> > second patch from you for this?
> 
> I can prepare a patch with description and sent it right now if you want

Sure that works. Then I'll stick both into tip/sched/urgent or
thereabout :-)

  reply	other threads:[~2026-01-23 10:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fyqsk63pkoxpeaclyqsm5nwtz3dyejplr7rg6p74xwemfzdzuu@7m7xhs5aqpqw>
2026-01-20 11:45 ` [PATCH] sched/fair: Disable scheduler feature NEXT_BUDDY Ryan Roberts
2026-01-22  3:53 ` Madadi Vineeth Reddy
2026-01-22 13:38 ` Ryan Roberts
2026-01-22 17:34   ` Vincent Guittot
2026-01-22 17:37     ` Vincent Guittot
2026-01-23  9:53     ` Peter Zijlstra
2026-01-23 10:04       ` Vincent Guittot
2026-01-23 10:09         ` Peter Zijlstra [this message]
2026-01-23 10:42           ` Vincent Guittot
2026-01-23 11:32             ` Ryan Roberts
2026-01-23 11:35               ` Vincent Guittot
2026-01-23 11:06 ` [tip: sched/urgent] " tip-bot2 for Mel Gorman

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=20260123100915.GL171111@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=Christian.Loehle@arm.com \
    --cc=clm@meta.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@techsingularity.net \
    --cc=mingo@redhat.com \
    --cc=ryan.roberts@arm.com \
    --cc=vincent.guittot@linaro.org \
    --cc=vineethr@linux.ibm.com \
    --cc=vschneid@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox