Re: [PATCH 6/6 v3] sched/eevdf: Speedup short slice task scheduling
From: Peter Zijlstra
Date: Fri Jun 26 2026 - 03:55:07 EST
On Fri, Jun 26, 2026 at 09:18:32AM +0200, Peter Zijlstra wrote:
> On Fri, Jun 26, 2026 at 09:05:29AM +0200, Vincent Guittot wrote:
> > On Fri, 26 Jun 2026 at 05:57, K Prateek Nayak <kprateek.nayak@xxxxxxx> wrote:
> > >
> > > Hello Peter,
> > >
> > > On 6/26/2026 3:58 AM, Peter Zijlstra wrote:
> > > > +static u64 ineligible_vruntime(struct cfs_rq *cfs_rq)
> > > > +{
> > > > + struct sched_entity *curr = cfs_rq->curr;
> > > > + long weight = cfs_rq->sum_weight;
> > > > + s64 delta = 0;
> > > > +
> > > > + if (curr && !curr->on_rq)
> > > > + curr = NULL;
> > > > +
> > > > + /*
> > > > + * This is called from set_next_task_fair(.first=true) /
> > > > + * set_protect_slice() so curr had better be set and on_rq.
> > > > + */
> > > > + WARN_ON_ONCE(!curr);
> > >
> > > set_protect_slice() is indeed called from set_next_entity(.first=true)
> > > but it is done after __dequeue_entity() and before "cfs_rq->curr" is
> > > set (both sched/flat and sched/core have the same pattern).
> >
> > Yes, I confirm that set_protect_slice() is called before setting curr
> > in tip/sched/core but I think that Peter added flat hierarchy patches
> > in his tree
>
> Indeed I did; I was planning to stick them in this cycle, so I figure I
> should be doing these patches on top.
I pushed out the now booting pile of gunk into queue:sched/core.
I've made some rando edits to your (Vincent's) patches, if you disagree
or want changes, let me know. This really is just my quilt stack of the
moment for sched/core and it can easily be changed.
/me wonders how the fuck it can be 28C before 10am and goes in search of
more water.