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>,
Clark Williams <clrkwllms@kernel.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
<linux-kernel@vger.kernel.org>, <linux-rt-devel@lists.linux.dev>,
<kernel-team@meta.com>
Subject: Re: Mapping from preempted task to running task on same CPU
Date: Fri, 16 Oct 2026 10:14:27 +0530 [thread overview]
Message-ID: <a92f4a71-614f-44e4-b4f1-38e92deffae2@amd.com> (raw)
In-Reply-To: <e8b6b372-d16b-4939-aa7a-755b7149e0fb@paulmck-laptop>
Hello Paul,
On 10/15/2026 11:11 PM, Paul E. McKenney wrote:
> Hello!
>
> One of the commits [1] that I used to chase down a recent bug [2] (and
> thank you again for the fix!) uses the scheduler-internal cpu_curr()
> macro to map from a given CPU to the task currently running on that CPU.
> In the commit, the actual operation is mapping from a stalled (AKA
> preempted but runnable) task to the task running on the corresponding CPU.
> This tasks's ->comm and ->pid are then printed in the RCU CPU stall
> warning console output.
>
> One of the real-time folks voted in favor being able to use this (the
> group is CCed here), which suggests that I push this commit to mainline.
> Which means that I need to do something other than my crude hack of
> creating a rcu_cpu_curr() function in kernel/sched/core.c to get access
> to the scheduler-private cpu_curr() macro.
>
> Please tell me what I should instead be doing (in the check_slow_task()
> function shown below) to get at this information.
[..snip..]
> @@ -327,6 +332,9 @@ static int check_slow_task(struct task_struct *t, void *arg)
> rscrp->on_blkd_list = !list_empty(&t->rcu_node_entry);
> rscrp->rcu_rdr_running = task_curr(t);
> rscrp->rcu_rdr_boosted = 0;
> + rscrp->rcu_rdr_cpu = cpu = task_cpu(t);
> + rscrp->rcu_rdr_cpu_offline = cpu_is_offline(cpu);
> + rscrp->rcu_rdr_cpu_task = th = rcu_cpu_curr(cpu);
If you don't mind taking the overhead of rq_lock, you can use
cpu_curr_snapshot(). It should give you gives a rcu protected
task struct of cpu_curr() and ...
> if (rscrp->on_blkd_list) {
> rnp = READ_ONCE(t->rcu_blocked_node);
> raw_spin_lock_rcu_node(rnp); /* irqs already disabled. */
> @@ -352,6 +360,7 @@ static int rcu_print_task_stall(struct rcu_node *rnp, unsigned long flags)
> int ndetected = 0;
> struct rcu_stall_chk_rdr rscr;
> struct task_struct *t;
> + struct task_struct *tc;
> struct task_struct *ts[8];
>
> lockdep_assert_irqs_disabled();
> @@ -372,17 +381,24 @@ static int rcu_print_task_stall(struct rcu_node *rnp, unsigned long flags)
> raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
> while (i) {
> t = ts[--i];
> - if (task_call_func(t, check_slow_task, &rscr))
> + if (task_call_func(t, check_slow_task, &rscr)) {
> pr_cont(" P%d", t->pid);
> - else
> - pr_cont(" P%d/%d:%c%c%c%c%c%c",
> + } else {
> + tc = rscr.rcu_rdr_cpu_task;
> + pr_cont(" P%d/%d:%c%c%c%c%c%c CPU %d%s %s (%d)%s",
> t->pid, rscr.nesting,
> ".b"[rscr.rs.b.blocked],
> ".q"[rscr.rs.b.need_qs],
> ".e"[rscr.rs.b.exp_hint],
> ".l"[rscr.on_blkd_list],
> ".R"[rscr.rcu_rdr_running],
> - ".B?"[rscr.rcu_rdr_boosted]);
> + ".B?"[rscr.rcu_rdr_boosted],
> + rscr.rcu_rdr_cpu,
> + rscr.rcu_rdr_cpu_offline ? "!" : "",
> + tc ? tc->comm : "???",
> + tc ? tc->pid : -1,
> + tc ? (is_idle_task(tc) ? " (idle!)" : "") : " (no task)");
> + }
> lockdep_assert_irqs_disabled();
... since you are IRQs disabled, it should be fine to use it here.
If you don't want to take the overhead of rq_lock() + barrier,
you can perhaps define a cpu_curr_snapshot_rcu() like:
struct task_struct *cpu_curr_snapshot_rcu(int cpu)
{
return rcu_dereference_all(cpu_curr(cpu));
}
in kernel/sched/core.c and expose it similar to
cpu_curr_snapshot().
I'll let Peter comment if he hates it or not ;-)
--
Thanks and Regards,
Prateek
next prev parent reply other threads:[~2026-10-16 4:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 17:41 Mapping from preempted task to running task on same CPU Paul E. McKenney
2026-10-16 4:44 ` K Prateek Nayak [this message]
2026-10-16 7:25 ` Peter Zijlstra
2026-10-16 16:08 ` Paul E. McKenney
2026-10-19 20:47 ` [PATCH] rcu: Print CPU that preempted stalled reader wants to run on Paul E. McKenney
2026-10-21 3:41 ` K Prateek Nayak
2026-10-21 4:03 ` Paul E. McKenney
2026-11-09 22:08 ` Paul E. McKenney
2026-11-09 22:18 ` sashiko-bot
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=a92f4a71-614f-44e4-b4f1-38e92deffae2@amd.com \
--to=kprateek.nayak@amd.com \
--cc=bigeasy@linutronix.de \
--cc=bsegall@google.com \
--cc=clrkwllms@kernel.org \
--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=linux-rt-devel@lists.linux.dev \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.