From: "Paul E. McKenney" <paulmck@kernel.org>
To: Robert Elliott <elliott@hpe.com>
Cc: herbert@gondor.apana.org.au, davem@davemloft.net,
frederic@kernel.org, quic_neeraju@quicinc.com,
josh@joshtriplett.org, linux-crypto@vger.kernel.org,
rcu@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] rcu: print first CPU on expedited stall line
Date: Wed, 21 Dec 2022 11:02:07 -0800 [thread overview]
Message-ID: <20221221190207.GC4001@paulmck-ThinkPad-P17-Gen-1> (raw)
In-Reply-To: <20221219202910.3063036-3-elliott@hpe.com>
On Mon, Dec 19, 2022 at 02:29:09PM -0600, Robert Elliott wrote:
> Include the first CPU number in the first pr_err() call reporting
> an expedited stall warning.
>
> Printing the CPU numbers with subsequent pr_cont() calls can
> result in the prints being many lines away or being dropped entirely
> in a busy system. This change ensures there is indication of at
> least one of the CPUs with the problem with the original message.
>
> Before (if prints are interspersed with other prints):
> rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: {
> 13-....
> } 32 jiffies s: 6685 root: 0x1/.
>
> After:
> rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: {13-....
> } 32 jiffies s: 6685 root: 0x1/.
>
> Signed-off-by: Robert Elliott <elliott@hpe.com>
A couple of questions below.
> ---
> kernel/rcu/tree_exp.h | 22 +++++++++++++++-------
> 1 file changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
> index ed6c3cce28f2..ade6a18e6c07 100644
> --- a/kernel/rcu/tree_exp.h
> +++ b/kernel/rcu/tree_exp.h
> @@ -624,8 +624,6 @@ static void synchronize_rcu_expedited_wait(void)
> if (rcu_stall_is_suppressed())
> continue;
> trace_rcu_stall_warning(rcu_state.name, TPS("ExpeditedStall"));
> - pr_err("INFO: %s detected expedited stalls on CPUs/tasks: {",
> - rcu_state.name);
> ndetected = 0;
> rcu_for_each_leaf_node(rnp) {
> ndetected += rcu_print_task_exp_stall(rnp);
> @@ -637,11 +635,21 @@ static void synchronize_rcu_expedited_wait(void)
> continue;
> ndetected++;
> rdp = per_cpu_ptr(&rcu_data, cpu);
> - pr_cont(" %d-%c%c%c%c", cpu,
> - "O."[!!cpu_online(cpu)],
> - "o."[!!(rdp->grpmask & rnp->expmaskinit)],
> - "N."[!!(rdp->grpmask & rnp->expmaskinitnext)],
> - "D."[!!(rdp->cpu_no_qs.b.exp)]);
> + // print the prefix and the first CPU number together
> + // under heavy load, the pr_cont prints can be far away or dropped
> + if (ndetected == 1)
Is the purpose here to print the header only on the first detected task?
If so, what if there is more than one task blocking the first rcu_node
structure? Wouldn't that omit the header entirely?
> + pr_err("INFO: %s detected expedited stalls on CPUs/tasks: {%d-%c%c%c%c",
We can of course get other console output interspersed at this point.
This might be OK in practice, but the commit log should clearly spell
out the reasons.
> + rcu_state.name, cpu,
> + "O."[!!cpu_online(cpu)],
> + "o."[!!(rdp->grpmask & rnp->expmaskinit)],
> + "N."[!!(rdp->grpmask & rnp->expmaskinitnext)],
> + "D."[!!(rdp->cpu_no_qs.b.exp)]);
> + else
> + pr_cont(" %d-%c%c%c%c", cpu,
> + "O."[!!cpu_online(cpu)],
> + "o."[!!(rdp->grpmask & rnp->expmaskinit)],
> + "N."[!!(rdp->grpmask & rnp->expmaskinitnext)],
> + "D."[!!(rdp->cpu_no_qs.b.exp)]);
> }
> }
> pr_cont(" } %lu jiffies s: %lu root: %#lx/%c\n",
> --
> 2.38.1
>
next prev parent reply other threads:[~2022-12-21 19:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-19 20:29 [PATCH 0/3] crypto/rcu: suppress unnecessary CPU stall warnings Robert Elliott
2022-12-19 20:29 ` [PATCH 1/3] rcu: genericize RCU stall suppression functions Robert Elliott
2022-12-21 18:56 ` Paul E. McKenney
2023-01-10 6:07 ` Joel Fernandes
2023-01-10 6:12 ` Joel Fernandes
2022-12-19 20:29 ` [PATCH 2/3] rcu: print first CPU on expedited stall line Robert Elliott
2022-12-21 19:02 ` Paul E. McKenney [this message]
2022-12-19 20:29 ` [PATCH 3/3] crypto: tcrypt - suppress RCU stall warnings during speed tests Robert Elliott
2022-12-30 8:39 ` Herbert Xu
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=20221221190207.GC4001@paulmck-ThinkPad-P17-Gen-1 \
--to=paulmck@kernel.org \
--cc=davem@davemloft.net \
--cc=elliott@hpe.com \
--cc=frederic@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=josh@joshtriplett.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_neeraju@quicinc.com \
--cc=rcu@vger.kernel.org \
/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®