mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>
To: <paulmck@kernel.org>
Cc: Frederic Weisbecker <frederic@kernel.org>,
	Neeraj Upadhyay <quic_neeraju@quicinc.com>,
	Josh Triplett <josh@joshtriplett.org>,
	"Steven Rostedt" <rostedt@goodmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Joel Fernandes <joel@joelfernandes.org>, <rcu@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, Robert Elliott <elliott@hpe.com>
Subject: Re: [PATCH] rcu: Illustrate the stall information of CONFIG_RCU_CPU_STALL_CPUTIME=y
Date: Wed, 9 Nov 2022 16:46:01 +0800	[thread overview]
Message-ID: <31c1dfb1-623f-4a9e-7f2c-48b83dd4490d@huawei.com> (raw)
In-Reply-To: <61c45ec1-69ec-0e65-6a48-1329e66ec30f@huawei.com>



On 2022/11/9 10:09, Leizhen (ThunderTown) wrote:
> 
> 
> On 2022/11/9 4:46, Paul E. McKenney wrote:
>> On Mon, Nov 07, 2022 at 11:29:35PM +0800, Zhen Lei wrote:
>>> Describes how to quickly determine the RCU stall fault type based on the
>>> extra output information during CONFIG_RCU_CPU_STALL_CPUTIME=y.
>>>
>>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>>
>> Hearing no objections, I queued the following for further review.
>>
>> This commit might of course need to change based on your ongoing
>> discussion with Robert.  I that case, please feel free to send me a
>> replacment patch or to send me an incremental patch that I can fold into
>> this patch.  Either way works.
> 
> I'll issue incremental patches on the basis of your adjustment! This will
> make it clearer and save your time in reviewing.

I found that Patch 4/4 had one line of description that needed to be changed,
so I had to switch to method 1.

> 
> Thanks for your help. I really admire your verbal skills. Your improved
> description is much better than mine.
> 
>>
>> 							Thanx, Paul
>>
>> ------------------------------------------------------------------------
>>
>> commit b05c2a06ff8a1267b7e8dc812e3944119535d6b6
>> Author: Zhen Lei <thunder.leizhen@huawei.com>
>> Date:   Mon Nov 7 23:29:35 2022 +0800
>>
>>     doc: Document CONFIG_RCU_CPU_STALL_CPUTIME=y stall information
>>     
>>     This commit doucments how to quickly determine the bug causing a given
>>     RCU CPU stall fault warning based on the output information provided
>>     by CONFIG_RCU_CPU_STALL_CPUTIME=y.
>>     
>>     [ paulmck: Apply wordsmithing. ]
>>     
>>     Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>>     Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
>>
>> diff --git a/Documentation/RCU/stallwarn.rst b/Documentation/RCU/stallwarn.rst
>> index dfa4db8c0931e..bd8cf6c640984 100644
>> --- a/Documentation/RCU/stallwarn.rst
>> +++ b/Documentation/RCU/stallwarn.rst
>> @@ -390,3 +390,82 @@ for example, "P3421".
>>  
>>  It is entirely possible to see stall warnings from normal and from
>>  expedited grace periods at about the same time during the same run.
>> +
>> +RCU_CPU_STALL_CPUTIME
>> +=====================
>> +
>> +In kernels built with CONFIG_RCU_CPU_STALL_CPUTIME=y or booted with
>> +rcupdate.rcu_cpu_stall_cputime=1, the following additional information
>> +is supplied with each RCU CPU stall warning::
>> +
>> +rcu:          hardirqs   softirqs   csw/system
>> +rcu:  number:      624         45            0
>> +rcu: cputime:       69          1         2425   ==> 2500(ms)
>> +
>> +These statistics are collected during the second half of the rcu stall
>> +timeout. The values in row "number:" are the number of hard interrupts,
>> +number of soft interrupts, and number of context switches on the stalled
>> +CPU. The first three values in row "cputime:" indicate the CPU time in
>> +milliseconds consumed by hard interrupts, soft interrupts, and tasks
>> +on the stalled CPU.  The last number is the measurement interval, again
>> +in milliseconds.  Because user-mode tasks normally do not cause RCU CPU
>> +stalls, these tasks are typically kernel tasks, which is why only the
>> +system CPU time are considered.
>> +
>> +The following describes four typical scenarios:
>> +
>> +1. A CPU looping with interrupts disabled.::
>> +
>> +   rcu:          hardirqs   softirqs   csw/system
>> +   rcu:  number:        0          0            0
>> +   rcu: cputime:        0          0            0   ==> 2500(ms)
>> +
>> +   Because interrupts have been disabled throughout the measurement
>> +   interval, there are no interrupts and no context switches.
>> +   Furthermore, because CPU time consumption was measured using interrupt
>> +   handlers, the system CPU consumption is misleadingly measured as zero.
>> +   This scenario will normally also have "(0 ticks this GP)" printed on
>> +   this CPU's summary line.
>> +
>> +2. A CPU looping with bottom halves disabled.
>> +
>> +   This is similar to the previous example, but with non-zero number of
>> +   and CPU time consumed by hard interrupts, along with non-zero CPU
>> +   time consumed by in-kernel execution.::
>> +
>> +   rcu:          hardirqs   softirqs   csw/system
>> +   rcu:  number:      624          0            0
>> +   rcu: cputime:       49          0         2446   ==> 2500(ms)
>> +
>> +   The fact that there are zero softirqs gives a hint that these were
>> +   disabled, perhaps via local_bh_disable().  It is of course possible
>> +   that there were no softirqs, perhaps because all events that would
>> +   result in softirq execution are confined to other CPUs.  In this case,
>> +   the diagnosis should continue as shown in the next example.
>> +
>> +3. A CPU looping with preemption disabled.
>> +
>> +   Here, only the number of context switches is zero.::
>> +
>> +   rcu:          hardirqs   softirqs   csw/system
>> +   rcu:  number:      624         45            0
>> +   rcu: cputime:       69          1         2425   ==> 2500(ms)
>> +
>> +   This situation hints that the stalled CPU was looping with preemption
>> +   disabled.
>> +
>> +4. No looping, but massive hard and soft interrupts.::
>> +
>> +   rcu:          hardirqs   softirqs   csw/system
>> +   rcu:  number:       xx         xx            0
>> +   rcu: cputime:       xx         xx            0   ==> 2500(ms)
>> +
>> +   Here, the number and CPU time of hard interrupts are all non-zero,
>> +   but the number of context switches and the in-kernel CPU time consumed
>> +   are zero. The number and cputime of soft interrupts will usually be
>> +   non-zero, but could be zero, for example, if the CPU was spinning
>> +   within a single hard interrupt handler.
>> +
>> +   If this type of RCU CPU stall warning can be reproduced, you can
>> +   narrow it down by looking at /proc/interrupts or by writing code to
>> +   trace each interrupt, for example, by referring to show_interrupts().
>> .
>>
> 

-- 
Regards,
  Zhen Lei

  reply	other threads:[~2022-11-09  8:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-07 15:29 Zhen Lei
2022-11-08 20:46 ` Paul E. McKenney
2022-11-09  2:09   ` Leizhen (ThunderTown)
2022-11-09  8:46     ` Leizhen (ThunderTown) [this message]
2022-11-09 15:56       ` Paul E. McKenney

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=31c1dfb1-623f-4a9e-7f2c-48b83dd4490d@huawei.com \
    --to=thunder.leizhen@huawei.com \
    --cc=elliott@hpe.com \
    --cc=frederic@kernel.org \
    --cc=jiangshanlai@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=paulmck@kernel.org \
    --cc=quic_neeraju@quicinc.com \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.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®