mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: K Prateek Nayak <kprateek.nayak@amd.com>
To: <paulmck@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>
Cc: 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 11:36:48 +0530	[thread overview]
Message-ID: <b2dd8374-63d4-4b04-9e2c-f6a84728f092@amd.com> (raw)
In-Reply-To: <8fa7f795-518c-4507-b684-60b0c1cac2c5@paulmck-laptop>

Hello Paul,

On 10/13/2026 12:11 AM, Paul E. McKenney wrote:
> The scheduler appears to lose wakeups on both x86 and arm64 systems
> when running the rcutorture TREE01 scenario with RCU priority boosting
> enabled, but without also enabling testing of RCU priority boosting.
> The following pair of commits in my -rcu tree [1] make these two changes:
> 
> c7684673c6ca ("EXP rcutorture: Enable RCU_BOOST where supported")
> 4b08261f7bff ("EXP rcutorture: Disable RCU priority boost testing on non-TREE03 scenarios")
> 
> These two changes were motivated by CI systems reporting RCU CPU stall
> warnings due to low-priority tasks being preempted for extended periods
> of time.  The hope is that undisciplined RCU priority boosting would
> eliminate these issues.  (For an example of a disciplined RCU priority
> boosting configuration, see the TREE03 scenario.)
> 
> The following command reproduces the lost-wakeup problem, which shows
> up as RCU CPU stall warnings caused by rcu_torture_reader() kthreads:
> 
> tools/testing/selftests/rcutorture/bin/kvm.sh --allcpus --duration 20m --configs '19*TREE01' --bootargs "nohz=off rcutorture.onoff_interval=0 rcutorture.nocbs_nthreads=0 rcutorture.shuffle_interval=0" --trust-make

tl;dr

I could hit that WARN_ON() from your debug patch with the above test
even under rq_lock. Seemed like a missing resched_curr() but it
turned out to also be related to rq->next_class interaction.

I haven't been able to hit the warnings with the below diff. Could
you please try this:

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 0f63c30b4324..f2f8af3cdfb5 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -11239,6 +11245,11 @@ void sched_change_end(struct sched_change_ctx *ctx)
 		if (p->sched_class->switched_to)
 			p->sched_class->switched_to(rq, p);
 
+		if (ctx->queued && sched_class_above(p->sched_class, rq->next_class)) {
+			rq->next_class = p->sched_class;
+			resched_curr(rq);
+		}
+
 		if (ctx->running) {
 			/*
 			 * If this was a class promotion; let the old class
---

Larger explanation
==================

I added more debug data and I see what happens at time of last wakeup:

    Last wakeup comm: rcu_torture_rea

    rq->next_class: 000000008d901c4b
    p->sched_class: 000000008d901c4b

    next_class:     idle?(0) fair?(1) rt?(0) dl?(0) stop?(0)
    p->sched class: idle?(0) fair?(1) rt?(0) dl?(0) stop?(0)

    need_resched_set_after_wakeup: 1


And then at the time when warning hits, we have:

    h_nr_runnable: 0
    h_nr_queued: 0
    rt_nr_running: 1
    rr_nr_running: 0
    dl_nr_running: 0

Looks like the task that is enqueued is RT but the enqueue context saw
it as a fair task which pointed to __sched_setscheduler().

When pick_task_fair() drops rq_lock() for newidle balance, it is
possible to queue a task and switch it to a higher class before the
CPU doing newidle balance grabs the rq_lock() again.

It then sees rq->next_class is still fair and only checks
"rq->cfs.h_nr_queued" which is now 0 because that task was moved to
RT. The task was not running so we neither upgraded the next_class,
nor did we do a resched.

sched_balance_newidle() returns 0 and since we are already at
pick_task_fair(), we think nothing has queued above us and bail out.
The above diff fixes rq->next_class and calls a resched_curr()
when the task in upgraded but not yet running.

Lightly tested with TREE01 which passes without complains after
adding the above diff. Your mileage may vary :-)

-- 
Thanks and Regards,
Prateek

=========================
Artifact: Full debug diff
=========================

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 0f63c30b4324..f2f8af3cdfb5 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2305,6 +2305,10 @@ void wakeup_preempt(struct rq *rq, struct task_struct *p, int flags)
 {
 	struct task_struct *donor = rq->donor;
 
+	rq->last_comm = p->comm;
+	rq->last_class = rq->next_class;
+	rq->wakeup_class = p->sched_class;
+
 	if (p->sched_class == rq->next_class) {
 		rq->next_class->wakeup_preempt(rq, p, flags);
 
@@ -2314,6 +2318,8 @@ void wakeup_preempt(struct rq *rq, struct task_struct *p, int flags)
 		rq->next_class = p->sched_class;
 	}
 
+	rq->nr_set_after_wakeup = test_tsk_need_resched(rq->curr);
+
 	/*
 	 * A queue event has occurred, and we're going to schedule.  In
 	 * this case, we can save a useless back to back clock update.
@@ -11239,6 +11245,11 @@ void sched_change_end(struct sched_change_ctx *ctx)
 		if (p->sched_class->switched_to)
 			p->sched_class->switched_to(rq, p);
 
+		if (ctx->queued && sched_class_above(p->sched_class, rq->next_class)) {
+			rq->next_class = p->sched_class;
+			resched_curr(rq);
+		}
+
 		if (ctx->running) {
 			/*
 			 * If this was a class promotion; let the old class
diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
index 76f3c84ca684..7a0f2f701d56 100644
--- a/kernel/sched/idle.c
+++ b/kernel/sched/idle.c
@@ -279,6 +279,7 @@ static void do_idle(void)
 {
 	int cpu = smp_processor_id();
 	bool got_tick = false;
+	struct rq *rq;
 
 	if (cpu_is_offline(cpu)) {
 		local_irq_disable();
@@ -306,6 +307,7 @@ static void do_idle(void)
 	tick_nohz_idle_enter();
 
 	while (!need_resched()) {
+		bool redo = false;
 
 		/*
 		 * Interrupts shouldn't be re-enabled from that point on until
@@ -339,6 +341,69 @@ static void do_idle(void)
 		 */
 		local_irq_disable();
 
+		/*
+		 * Lost-kick safety net: never sleep with genuinely runnable
+		 * work queued.  Exclude delayed-dequeue tasks, which are
+		 * counted in nr_running but not pickable (as in
+		 * wake_affine_idle()).  Lockless reads are fine: a spurious
+		 * hit costs one extra schedule pass, a miss is re-checked
+		 * on the next tick/interrupt.
+		 */
+		rq = this_rq();
+
+		scoped_guard (rq_lock, rq) {
+			struct rq_flags *rf = &scope.rf;
+
+			if ((READ_ONCE(rq->nr_running) >
+			    READ_ONCE(rq->cfs.h_nr_queued) - READ_ONCE(rq->cfs.h_nr_runnable)) &&
+			    !need_resched()) {
+				WARN_ONCE(1, "CPU %d entering idle with %u runnable tasks queued\n",
+					  cpu, READ_ONCE(rq->nr_running));
+
+				pr_warn("Last comm: %s\n", rq->last_comm);
+				pr_warn("Last class: %p\n", rq->last_class);
+				pr_warn("Wakeup class: %p\n", rq->wakeup_class);
+
+				pr_warn("Last class: idle?(%d) fair?(%d) rt?(%d) dl?(%d) stop?(%d)\n",
+						rq->last_class == &idle_sched_class,
+						rq->last_class == &fair_sched_class,
+						rq->last_class == &rt_sched_class,
+						rq->last_class == &dl_sched_class,
+						rq->last_class == &stop_sched_class);
+
+				pr_warn("Wake class: idle?(%d) fair?(%d) rt?(%d) dl?(%d) stop?(%d)\n",
+						rq->wakeup_class == &idle_sched_class,
+						rq->wakeup_class == &fair_sched_class,
+						rq->wakeup_class == &rt_sched_class,
+						rq->wakeup_class == &dl_sched_class,
+						rq->wakeup_class == &stop_sched_class);
+
+				pr_warn("nr_set_after_wakeup: %d\n", rq->nr_set_after_wakeup);
+				pr_warn("h_nr_runnable: %u\n", rq->cfs.h_nr_runnable);
+				pr_warn("h_nr_queued: %u\n", rq->cfs.h_nr_queued);
+
+				pr_warn("rt_nr_running: %u\n",  rq->rt.rt_nr_running);
+				pr_warn("rr_nr_running: %u\n",  rq->rt.rr_nr_running);
+				pr_warn("dl_nr_running: %u\n",  rq->dl.dl_nr_running);
+
+
+				if (rq->cfs.h_nr_queued) {
+					update_rq_clock(rq);
+					pr_warn("Pick on fair: %p\n", fair_sched_class.pick_task(rq, rf));
+				}
+
+				// set_tsk_need_resched(current);
+				// redo = true;
+				break;
+			}
+		}
+
+		if (redo) {
+			local_irq_enable();
+			continue;
+		}
+
+
 		arch_cpu_idle_enter();
 		rcu_nocb_flush_deferred_wakeup();
 
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 7d2ec527b8a2..7e685cc51e43 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1253,6 +1253,11 @@ struct rq {
 	unsigned long		next_balance;
 	struct mm_struct	*prev_mm;
 
+	char			*last_comm;
+	const struct sched_class	*last_class;
+	const struct sched_class	*wakeup_class;
+	int			nr_set_after_wakeup;
+
 	/*
 	 * The following fields of clock data are frequently referenced
 	 * and updated together, and should go on their own cache line.
---

  reply	other threads:[~2026-10-13  6:07 UTC|newest]

Thread overview: 20+ 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 [this message]
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
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-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=b2dd8374-63d4-4b04-9e2c-f6a84728f092@amd.com \
    --to=kprateek.nayak@amd.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=joelagnelf@nvidia.com \
    --cc=juri.lelli@redhat.com \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.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®