From: Peter Zijlstra <peterz@infradead.org>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: K Prateek Nayak <kprateek.nayak@amd.com>,
paulmck@kernel.org, Ingo Molnar <mingo@redhat.com>,
Juri Lelli <juri.lelli@redhat.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>,
Joel Fernandes <joelagnelf@nvidia.com>,
linux-kernel@vger.kernel.org, kernel-team@meta.com
Subject: Re: [BUG] Apparent lost wakeups
Date: Tue, 13 Oct 2026 12:14:52 +0200 [thread overview]
Message-ID: <20261013101452.GG2009045@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <CAKfTPtDz35egMZEVz+wb5kytgVrv7APcVOYBkCByvzPSCH7Meg@mail.gmail.com>
On Tue, Oct 13, 2026 at 09:58:25AM +0200, Vincent Guittot wrote:
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index 0f63c30b4324..b37c771c41ad 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -11256,6 +11262,9 @@ void sched_change_end(struct sched_change_ctx *ctx)
> if (ctx->running) {
> /*
> * If this was a class promotion; let the old class
> * know it got preempted. Note that none of the
> * switch*_from() methods know the new class and none
> * of the switch*_to() methods know the old class.
> */
> if (sched_class_above(p->sched_class, ctx->class)) {
> rq->next_class->wakeup_preempt(rq, p, 0);
> rq->next_class = p->sched_class;
> }
> /*
> * If this was a degradation in class; make sure to
> * reschedule.
> > */
> > if (sched_class_above(ctx->class, p->sched_class))
> > resched_curr(rq);
> > + } else if (ctx->queued) {
> > + /* Check if we need can preempt the current task. */
> > + wakeup_preempt(rq, p, 0);
>
> Isn't what we have for ctx->running above what we also want in this case ?
> Then sched_balance_newidle() will detect it with
>
> /* If a higher prio class was modified, restart the pick */
> if (rq_modified_above(this_rq, &fair_sched_class))
> pulled_task = -1;
>
Ah, I'm maybe slowly starting to see the shape of this. Does something
like so make sense?
That is, any task on the rq cares about promotion, only the current
running task cares about demotion.
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 047fbe8ef298..2a8bf562a769 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -11261,7 +11261,7 @@ void sched_change_end(struct sched_change_ctx *ctx)
if (p->sched_class->switched_to)
p->sched_class->switched_to(rq, p);
- if (ctx->running) {
+ if (ctx->queued) {
/*
* If this was a class promotion; let the old class
* know it got preempted. Note that none of the
@@ -11272,6 +11272,9 @@ void sched_change_end(struct sched_change_ctx *ctx)
rq->next_class->wakeup_preempt(rq, p, 0);
rq->next_class = p->sched_class;
}
+ }
+
+ if (ctx->running) {
/*
* If this was a degradation in class; make sure to
* reschedule.
next prev parent reply other threads:[~2026-10-13 10:15 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 18:41 Paul E. McKenney
2026-10-13 6:06 ` K Prateek Nayak
2026-10-13 6:46 ` K Prateek Nayak
2026-10-13 7:58 ` Vincent Guittot
2026-10-13 8:30 ` K Prateek Nayak
2026-10-13 8:36 ` Vincent Guittot
2026-10-13 10:14 ` Peter Zijlstra [this message]
2026-10-13 10:29 ` K Prateek Nayak
2026-10-13 10:37 ` Peter Zijlstra
2026-10-13 10:43 ` K Prateek Nayak
2026-10-13 10:06 ` Peter Zijlstra
2026-10-13 15:24 ` [PATCH] sched/core: Call wakeup_preempt() for queued tasks during class change K Prateek Nayak
2026-10-13 16:45 ` Vincent Guittot
2026-10-13 17:57 ` Paul E. McKenney
2026-10-13 19:55 ` Paul E. McKenney
2026-10-13 20:06 ` Paul E. McKenney
2026-10-14 0:13 ` Paul E. McKenney
2026-10-14 6:37 ` K Prateek Nayak
2026-10-14 10:59 ` Phil Auld
2026-10-13 12:49 [BUG] Apparent lost wakeups Joel Fernandes
2026-10-13 14:00 ` K Prateek Nayak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261013101452.GG2009045@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=joelagnelf@nvidia.com \
--cc=juri.lelli@redhat.com \
--cc=kernel-team@meta.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=paulmck@kernel.org \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®