[PATCH] sched/eevdf: Delayed dequeue task can't preempt

[PATCH] sched/eevdf: Delayed dequeue task can't preempt

[Vincent Guittot]

Load balancing can migrate delayed dequeue tasks to even the load between
CPUs.

sched_balance_rq()
  -> detach_task()
    -> deactivate_task(DEQUEUE_NOCLOCK)
    -> set_task_cpu(dst_cpu)

  -> attach_task()
    -> activate_task(ENQUEUE_NOCLOCK)
    -> wakeup_preempt()

A delayed task with shorter slice can be dequeued during pick_next_entity()
but then jump to preempt because eligible.

Always jump to update for delayed dequeue task even with shorter slice.

Fixes: ba0d3bf5f97b ("sched/eevdf: Cancel slice protection if short slice task is eligible")
Reported-by: K Prateek Nayak <kprateek.nayak@amd.com>
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
---
 kernel/sched/fair.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index fc6cd55f9d22..df8c9c2c7918 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -9948,6 +9948,13 @@ static void wakeup_preempt_fair(struct rq *rq, struct task_struct *p, int wake_f
 	if (unlikely(!normal_policy(p->policy)))
 		goto update;
 
+	/*
+	 * Do not preempt for tasks that are sched_delayed as it would violate
+	 * EEVDF to forcibly queue an ineligible task.
+	 */
+	if (pse->sched_delayed)
+		goto update;
+
 	/*
 	 * If @p has a shorter slice than current and @p is eligible, override
 	 * current's slice protection in order to allow preemption.
@@ -9959,11 +9966,9 @@ static void wakeup_preempt_fair(struct rq *rq, struct task_struct *p, int wake_f
 
 	/*
 	 * Ignore wakee preemption on WF_FORK as it is less likely that
-	 * there is shared data as exec often follow fork. Do not
-	 * preempt for tasks that are sched_delayed as it would violate
-	 * EEVDF to forcibly queue an ineligible task.
+	 * there is shared data as exec often follow fork.
 	 */
-	if ((wake_flags & WF_FORK) || pse->sched_delayed)
+	if (wake_flags & WF_FORK)
 		goto update;
 
 	/* Prefer picking wakee soon if appropriate. */
-- 
2.43.0

Re: [PATCH] sched/eevdf: Delayed dequeue task can't preempt

[K Prateek Nayak]

Hello Vincent,

On 7/1/2026 10:19 PM, Vincent Guittot wrote:
> Load balancing can migrate delayed dequeue tasks to even the load between
> CPUs.
> 
> sched_balance_rq()
>   -> detach_task()
>     -> deactivate_task(DEQUEUE_NOCLOCK)
>     -> set_task_cpu(dst_cpu)
> 
>   -> attach_task()
>     -> activate_task(ENQUEUE_NOCLOCK)
>     -> wakeup_preempt()
> 
> A delayed task with shorter slice can be dequeued during pick_next_entity()
> but then jump to preempt because eligible.
> 
> Always jump to update for delayed dequeue task even with shorter slice.
> 
> Fixes: ba0d3bf5f97b ("sched/eevdf: Cancel slice protection if short slice task is eligible")
> Reported-by: K Prateek Nayak <kprateek.nayak@amd.com>
> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>

Thank you for fixing this! Feel free to include:

Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>

> ---
>  kernel/sched/fair.c | 13 +++++++++----
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index fc6cd55f9d22..df8c9c2c7918 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -9948,6 +9948,13 @@ static void wakeup_preempt_fair(struct rq *rq, struct task_struct *p, int wake_f
>  	if (unlikely(!normal_policy(p->policy)))
>  		goto update;
>  
> +	/*
> +	 * Do not preempt for tasks that are sched_delayed as it would violate
> +	 * EEVDF to forcibly queue an ineligible task.
> +	 */
> +	if (pse->sched_delayed)
> +		goto update;
> +

Small question: Are we updating the protect slice just to maintain the
lag bounds with delayed entities?

Otherwise, it might be okay to return early here and keep the current
running for a bit longer and wait until the delayed entity gets a wakeup
which does a wakeup_preempt().

/me goes and checks

My hackbench run says:

  Test:                  vanilla              early_return
   1-groups:         4.75 (0.00 pct)         4.46 ( 6.10 pct)
   2-groups:         4.52 (0.00 pct)         4.57 (-1.10 pct)
   4-groups:         4.67 (0.00 pct)         4.73 (-1.28 pct)
   8-groups:         7.09 (0.00 pct)         6.85 ( 3.38 pct)
  16-groups:        12.07 (0.00 pct)        12.03 ( 0.33 pct)

but there is enough variance in the improved runs that it could all be
noise so your patch should be good as is.

-- 
Thanks and Regards,
Prateek

Re: [PATCH] sched/eevdf: Delayed dequeue task can't preempt

[Peter Zijlstra]

On Wed, Jul 01, 2026 at 06:49:20PM +0200, Vincent Guittot wrote:
> Load balancing can migrate delayed dequeue tasks to even the load between
> CPUs.
> 
> sched_balance_rq()
>   -> detach_task()
>     -> deactivate_task(DEQUEUE_NOCLOCK)
>     -> set_task_cpu(dst_cpu)
> 
>   -> attach_task()
>     -> activate_task(ENQUEUE_NOCLOCK)
>     -> wakeup_preempt()
> 
> A delayed task with shorter slice can be dequeued during pick_next_entity()
> but then jump to preempt because eligible.

Cute.

Perhaps we can look at enqueue()'s place entity and determine
eligibility there and complete the delayed dequeue there. But that's
definitely something for after the holidays I suppose.

I'll go stick it in tip/sched/core.

[tip: sched/core] sched/eevdf: Delayed dequeue task can't preempt

[tip-bot2 for Vincent Guittot]

The following commit has been merged into the sched/core branch of tip:

Commit-ID:     04998aa54848f15332202d0bea008d2ca1ed1713
Gitweb:        https://git.kernel.org/tip/04998aa54848f15332202d0bea008d2ca1ed1713
Author:        Vincent Guittot <vincent.guittot@linaro.org>
AuthorDate:    Wed, 01 Jul 2026 18:49:20 +02:00
Committer:     Peter Zijlstra <peterz@infradead.org>
CommitterDate: Thu, 02 Jul 2026 09:43:17 +02:00

sched/eevdf: Delayed dequeue task can't preempt

Load balancing can migrate delayed dequeue tasks to even the load between
CPUs.

sched_balance_rq()
  -> detach_task()
    -> deactivate_task(DEQUEUE_NOCLOCK)
    -> set_task_cpu(dst_cpu)

  -> attach_task()
    -> activate_task(ENQUEUE_NOCLOCK)
    -> wakeup_preempt()

A delayed task with shorter slice can be dequeued during pick_next_entity()
but then jump to preempt because eligible.

Always jump to update for delayed dequeue task even with shorter slice.

Fixes: ba0d3bf5f97b ("sched/eevdf: Cancel slice protection if short slice task is eligible")
Reported-by: K Prateek Nayak <kprateek.nayak@amd.com>
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Link: https://patch.msgid.link/20260701164920.1571352-1-vincent.guittot@linaro.org
---
 kernel/sched/fair.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index fc6cd55..df8c9c2 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -9949,6 +9949,13 @@ static void wakeup_preempt_fair(struct rq *rq, struct task_struct *p, int wake_f
 		goto update;
 
 	/*
+	 * Do not preempt for tasks that are sched_delayed as it would violate
+	 * EEVDF to forcibly queue an ineligible task.
+	 */
+	if (pse->sched_delayed)
+		goto update;
+
+	/*
 	 * If @p has a shorter slice than current and @p is eligible, override
 	 * current's slice protection in order to allow preemption.
 	 */
@@ -9959,11 +9966,9 @@ static void wakeup_preempt_fair(struct rq *rq, struct task_struct *p, int wake_f
 
 	/*
 	 * Ignore wakee preemption on WF_FORK as it is less likely that
-	 * there is shared data as exec often follow fork. Do not
-	 * preempt for tasks that are sched_delayed as it would violate
-	 * EEVDF to forcibly queue an ineligible task.
+	 * there is shared data as exec often follow fork.
 	 */
-	if ((wake_flags & WF_FORK) || pse->sched_delayed)
+	if (wake_flags & WF_FORK)
 		goto update;
 
 	/* Prefer picking wakee soon if appropriate. */

Re: [PATCH] sched/eevdf: Delayed dequeue task can't preempt

[Vincent Guittot]

On Thu, 2 Jul 2026 at 06:56, K Prateek Nayak <kprateek.nayak@amd.com> wrote:
>
> Hello Vincent,
>
> On 7/1/2026 10:19 PM, Vincent Guittot wrote:
> > Load balancing can migrate delayed dequeue tasks to even the load between
> > CPUs.
> >
> > sched_balance_rq()
> >   -> detach_task()
> >     -> deactivate_task(DEQUEUE_NOCLOCK)
> >     -> set_task_cpu(dst_cpu)
> >
> >   -> attach_task()
> >     -> activate_task(ENQUEUE_NOCLOCK)
> >     -> wakeup_preempt()
> >
> > A delayed task with shorter slice can be dequeued during pick_next_entity()
> > but then jump to preempt because eligible.
> >
> > Always jump to update for delayed dequeue task even with shorter slice.
> >
> > Fixes: ba0d3bf5f97b ("sched/eevdf: Cancel slice protection if short slice task is eligible")
> > Reported-by: K Prateek Nayak <kprateek.nayak@amd.com>
> > Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
>
> Thank you for fixing this! Feel free to include:
>
> Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
> Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
>
> > ---
> >  kernel/sched/fair.c | 13 +++++++++----
> >  1 file changed, 9 insertions(+), 4 deletions(-)
> >
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index fc6cd55f9d22..df8c9c2c7918 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -9948,6 +9948,13 @@ static void wakeup_preempt_fair(struct rq *rq, struct task_struct *p, int wake_f
> >       if (unlikely(!normal_policy(p->policy)))
> >               goto update;
> >
> > +     /*
> > +      * Do not preempt for tasks that are sched_delayed as it would violate
> > +      * EEVDF to forcibly queue an ineligible task.
> > +      */
> > +     if (pse->sched_delayed)
> > +             goto update;
> > +
>
> Small question: Are we updating the protect slice just to maintain the
> lag bounds with delayed entities?

Yes, maintaining the lag for delayed entities also helps to maintain
lag for other entities


>
> Otherwise, it might be okay to return early here and keep the current
> running for a bit longer and wait until the delayed entity gets a wakeup
> which does a wakeup_preempt().
>
> /me goes and checks
>
> My hackbench run says:
>
>   Test:                  vanilla              early_return
>    1-groups:         4.75 (0.00 pct)         4.46 ( 6.10 pct)
>    2-groups:         4.52 (0.00 pct)         4.57 (-1.10 pct)
>    4-groups:         4.67 (0.00 pct)         4.73 (-1.28 pct)
>    8-groups:         7.09 (0.00 pct)         6.85 ( 3.38 pct)
>   16-groups:        12.07 (0.00 pct)        12.03 ( 0.33 pct)
>
> but there is enough variance in the improved runs that it could all be
> noise so your patch should be good as is.
>
> --
> Thanks and Regards,
> Prateek
>

Re: [PATCH] sched/eevdf: Delayed dequeue task can't preempt

[Vincent Guittot]

On Thu, 2 Jul 2026 at 09:43, Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Wed, Jul 01, 2026 at 06:49:20PM +0200, Vincent Guittot wrote:
> > Load balancing can migrate delayed dequeue tasks to even the load between
> > CPUs.
> >
> > sched_balance_rq()
> >   -> detach_task()
> >     -> deactivate_task(DEQUEUE_NOCLOCK)
> >     -> set_task_cpu(dst_cpu)
> >
> >   -> attach_task()
> >     -> activate_task(ENQUEUE_NOCLOCK)
> >     -> wakeup_preempt()
> >
> > A delayed task with shorter slice can be dequeued during pick_next_entity()
> > but then jump to preempt because eligible.
>
> Cute.
>
> Perhaps we can look at enqueue()'s place entity and determine
> eligibility there and complete the delayed dequeue there. But that's
> definitely something for after the holidays I suppose.
>
> I'll go stick it in tip/sched/core.

Maybe better in tip/sched/urgent because of the warn triggered in set_next_buddy

Re: [PATCH] sched/eevdf: Delayed dequeue task can't preempt

[Peter Zijlstra]

On Thu, Jul 02, 2026 at 09:53:13AM +0200, Vincent Guittot wrote:
> On Thu, 2 Jul 2026 at 09:43, Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Wed, Jul 01, 2026 at 06:49:20PM +0200, Vincent Guittot wrote:
> > > Load balancing can migrate delayed dequeue tasks to even the load between
> > > CPUs.
> > >
> > > sched_balance_rq()
> > >   -> detach_task()
> > >     -> deactivate_task(DEQUEUE_NOCLOCK)
> > >     -> set_task_cpu(dst_cpu)
> > >
> > >   -> attach_task()
> > >     -> activate_task(ENQUEUE_NOCLOCK)
> > >     -> wakeup_preempt()
> > >
> > > A delayed task with shorter slice can be dequeued during pick_next_entity()
> > > but then jump to preempt because eligible.
> >
> > Cute.
> >
> > Perhaps we can look at enqueue()'s place entity and determine
> > eligibility there and complete the delayed dequeue there. But that's
> > definitely something for after the holidays I suppose.
> >
> > I'll go stick it in tip/sched/core.
> 
> Maybe better in tip/sched/urgent because of the warn triggered in set_next_buddy

Hmm, but the Fixes tag you gave it reference a patch in sched/core; is
that tag wrong? Or do I just need to imbibe more wakeup juice?

Re: [PATCH] sched/eevdf: Delayed dequeue task can't preempt

[Vincent Guittot]

On Thu, 2 Jul 2026 at 11:01, Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Thu, Jul 02, 2026 at 09:53:13AM +0200, Vincent Guittot wrote:
> > On Thu, 2 Jul 2026 at 09:43, Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > > On Wed, Jul 01, 2026 at 06:49:20PM +0200, Vincent Guittot wrote:
> > > > Load balancing can migrate delayed dequeue tasks to even the load between
> > > > CPUs.
> > > >
> > > > sched_balance_rq()
> > > >   -> detach_task()
> > > >     -> deactivate_task(DEQUEUE_NOCLOCK)
> > > >     -> set_task_cpu(dst_cpu)
> > > >
> > > >   -> attach_task()
> > > >     -> activate_task(ENQUEUE_NOCLOCK)
> > > >     -> wakeup_preempt()
> > > >
> > > > A delayed task with shorter slice can be dequeued during pick_next_entity()
> > > > but then jump to preempt because eligible.
> > >
> > > Cute.
> > >
> > > Perhaps we can look at enqueue()'s place entity and determine
> > > eligibility there and complete the delayed dequeue there. But that's
> > > definitely something for after the holidays I suppose.
> > >
> > > I'll go stick it in tip/sched/core.
> >
> > Maybe better in tip/sched/urgent because of the warn triggered in set_next_buddy
>
> Hmm, but the Fixes tag you gave it reference a patch in sched/core; is
> that tag wrong? Or do I just need to imbibe more wakeup juice?

No, I need more wakeup juice. Yeah it's tip/sched/core not 7.2-rc1