Re: [PATCH 4/6 v3] sched/eevdf: Cancel slice protection if short slice task is eligible
From: Shubhang Kaushik
Date: Fri Jun 26 2026 - 01:54:03 EST
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
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.
Regards,
+
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
Shubhang Kaushik