Re: [PATCH 4/6 v3] sched/eevdf: Cancel slice protection if short slice task is eligible

[Vincent Guittot]

Hi Shubhang,

On Fri, 26 Jun 2026 at 07:52, Shubhang Kaushik
<shubhang@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> Hi Vincent,
>
> On Thu, 25 Jun 2026, Vincent Guittot wrote:
>
> > On Thu, 25 Jun 2026 at 08:00, K Prateek Nayak <kprateek.nayak@xxxxxxx> wrote:
> >>
> >> Hello Vincent,
> >>
> >> On 6/24/2026 8:42 PM, Vincent Guittot wrote:
> >>> @@ -9896,16 +9891,23 @@ static void wakeup_preempt_fair(struct rq *rq, struct task_struct *p, int wake_f
> >>>       if (!nse && cfs_rq->nr_queued)
> >>>               goto pick;
> >>>
> >>> +     /*
> >>> +      * If @p is eligible but not the next task to run then cancel protection
> >>> +      * to prevent large scheduling latency
> >>> +      */
> >>> +     if (preempt_action == PREEMPT_WAKEUP_SHORT && entity_eligible(cfs_rq, pse))
> >>> +             goto preempt;
> >>
> >> We handle "pse->slice < se->slice" case before "pse->sched_delayed" case
> >> and jump to "pick", but pse can get dequeued as a part of
> >> pick_next_entity() if it was delayed and picked.
> >
> > yes
> >
> >>
> >> I think we can reach here for PREEMPT_WAKEUP_SHORT after pse is
> >> completely dequeued from cfs_rq. If p is a task on root cfs_rq, we could
> >> have blocked the task entirely and ideally it shouldn't be referenced
> >> here.
> >
> > I tried to find which use case calls wakeup_preempt_fair() for a
> > sched_delayed task but can't find it
> >
> >>
> >> Since a wakeup of delayed entity / on delayed hierarchy will call
> >> wakeup_preempt() anyways, I think we should return early if we should
> >> directly jump to update if we see "pse->sched_delayed".
> >
> > Fair enough. But we still need to consider the FORK case
> >
>
> I tested the v3 series on Ampere Altra using cyclictest with high
> concurrency rt-app and hackbench load matrices. I tried to follow your
> same setup for the testsuite as described in the cover letter
> with the baseline as tip/sched/core.
>
> The maximum latency changed as follows:-
>         - cyclictest: 112us -> 62us
>         - cyclictest + rt-app: 108us -> 166us
>         - cyclictest + hackbench: 173us -> 154us

Thanks for testing. Your max values were already really short compared
to my figures. It doesn't seem that cyclictest is really affected by
other activities. You should increase the load of hackbench with more
groups as an example.

Also, How long did you run your tests? I ran each test for 133 seconds
to try to catch most of the corner cases

>
> The patchset improved the two cases above but regresses the rt-app tail.
> Would the regression be caused by the interaction between the larger
> competing slices and repeated short task wakeups? These repeatedly tend
> to cancel or recompute the running entity's protection.

I don't think this has an impact.
I haven't included the average and median values because they were similar.
- median value remains the same: 57us
- avg value was better with the use case involving rt-app: 231us vs 168us


>
> >>
> >>> +
> >>>       if (sched_feat(RUN_TO_PARITY))
> >>>               update_protect_slice(cfs_rq, se);
> >>>
> >>>       return;
> >>>
> >>>  preempt:
> >>> -     if (preempt_action == PREEMPT_WAKEUP_SHORT) {
> >>> -             cancel_protect_slice(se);
> >>> +     cancel_protect_slice(se);
> >>> +
> >>> +     if (preempt_action == PREEMPT_WAKEUP_SHORT && nse == pse)
> >>>               set_next_buddy(&p->se);
> >>> -     }
> >>>
> >>>       resched_curr_lazy(rq);
> >>>  }
> >>
> >> --
> >> Thanks and Regards,
> >> Prateek
> >>
> >
> Regards,
> Shubhang Kaushik