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

[Shubhang Kaushik <shubhang@os.amperecomputing.com>]

Hi Vincent,

On Thu, 25 Jun 2026, Vincent Guittot wrote:

> On Thu, 25 Jun 2026 at 08:00, K Prateek Nayak <kprateek.nayak@amd.com> 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

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.

>>
>>> +
>>>       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