Linux RCU subsystem development
 help / color / mirror / Atom feed
From: Neeraj Upadhyay <neeraju@codeaurora.org>
To: Sangmoon Kim <sangmoon.kim@samsung.com>, paulmck@kernel.org
Cc: jiangshanlai@gmail.com, joel@joelfernandes.org,
	josh@joshtriplett.org, mathieu.desnoyers@efficios.com,
	rcu@vger.kernel.org, rostedt@goodmis.org
Subject: Re: [PATCH] rcu/tree: Add a trace event for RCU stall warnings
Date: Wed, 17 Feb 2021 23:47:44 +0530	[thread overview]
Message-ID: <bf80e296-14bf-6f36-8952-416829d30e5a@codeaurora.org> (raw)
In-Reply-To: <20210217134947.19055-1-sangmoon.kim@samsung.com>

Hi Sangmoon,

On 2/17/2021 7:19 PM, Sangmoon Kim wrote:
>> -----Original Message-----
>> From: Paul E. McKenney <paulmck@kernel.org>
>> Sent: Wednesday, February 17, 2021 2:50 AM
>>
>> On Mon, Feb 15, 2021 at 05:53:25PM +0900, Sangmoon Kim wrote:
>>> The event allows us to trace the RCU stall when
>>> sysctl_panic_on_rcu_stall is disabled.
>>>
>>> The first parameter is the name of RCU flavour like other trace
>>> events. The second one shows us which function detected stalls.
>>>
>>> The RCU stall is mainly caused by external factors such as interrupt
>>> handling or task scheduling or something else. Therefore, this event
>>> uses TRACE_EVENT macro, not dedicated one, so that someone interested
>>> in the RCU stall can use it without CONFIG_RCU_TRACE.
>>>
>>> Signed-off-by: Sangmoon Kim <sangmoon.kim@samsung.com>
>>
>> The patch looks plausible, but I have to ask...  Why not instead just
>> get the existing information out of the console log?
>>
>> 							Thanx, Paul
> 
> This can provide a trigger point for the RCU stall warning.
> If a module in the kernel wants to trace the stall for debugging purposes,
> there is a cost of continuing to parse the console log.
> This tracepoint is useful because it is hard to pay these costs
> especially on mobile devices.
> 
> Thanks,
> Sangmoon
> 

So, the idea here is to register to these trace events from kernel 
module and use that for debugging? Just curious what debugging action
module does on these traces, as they have limited information
about the stall, compared to console stall warnings, which gives a
much more detailed information about stall.


Thanks
Neeraj

>>
>>> ---
>>>   include/trace/events/rcu.h | 28 ++++++++++++++++++++++++++++
>>>   kernel/rcu/tree_exp.h      |  2 ++
>>>   kernel/rcu/tree_stall.h    |  2 ++
>>>   3 files changed, 32 insertions(+)
>>>
>>> diff --git a/include/trace/events/rcu.h b/include/trace/events/rcu.h
>>> index 155b5cb43cfd..8476f3161bd0 100644
>>> --- a/include/trace/events/rcu.h
>>> +++ b/include/trace/events/rcu.h
>>> @@ -432,6 +432,34 @@ TRACE_EVENT_RCU(rcu_fqs,
>>>   		  __entry->cpu, __entry->qsevent)
>>>   );
>>>
>>> +/*
>>> + * Tracepoint for RCU stall events. Takes a string identifying the RCU flavor
>>> + * and a string identifying which function detected the RCU stall as follows:
>>> + *
>>> + *	"StallDetected": Scheduler-tick detects other CPU's stalls.
>>> + *	"SelfDetected": Scheduler-tick detects a current CPU's stall.
>>> + *	"ExpeditedStall": Expedited grace period detects stalls.
>>> + */
>>> +TRACE_EVENT(rcu_stall_warning,
>>> +
>>> +	TP_PROTO(const char *rcuname, const char *msg),
>>> +
>>> +	TP_ARGS(rcuname, msg),
>>> +
>>> +	TP_STRUCT__entry(
>>> +		__field(const char *, rcuname)
>>> +		__field(const char *, msg)
>>> +	),
>>> +
>>> +	TP_fast_assign(
>>> +		__entry->rcuname = rcuname;
>>> +		__entry->msg = msg;
>>> +	),
>>> +
>>> +	TP_printk("%s %s",
>>> +		  __entry->rcuname, __entry->msg)
>>> +);
>>> +
>>>   #endif /* #if defined(CONFIG_TREE_RCU) */
>>>
>>>   /*
>>> diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
>>> index 8760b6ead770..c16618284cb2 100644
>>> --- a/kernel/rcu/tree_exp.h
>>> +++ b/kernel/rcu/tree_exp.h
>>> @@ -566,6 +566,8 @@ static void synchronize_rcu_expedited_wait(void)
>>>   				dump_cpu_task(cpu);
>>>   			}
>>>   		}
>>> +		trace_rcu_stall_warning(rcu_state.name, TPS("ExpeditedStall"));
>>> +
>>>   		jiffies_stall = 3 * rcu_jiffies_till_stall_check() + 3;
>>>   	}
>>>   }
>>> diff --git a/kernel/rcu/tree_stall.h b/kernel/rcu/tree_stall.h
>>> index 70d48c52fabc..e93df4fac5b1 100644
>>> --- a/kernel/rcu/tree_stall.h
>>> +++ b/kernel/rcu/tree_stall.h
>>> @@ -531,6 +531,7 @@ static void print_other_cpu_stall(unsigned long gp_seq, unsigned long gps)
>>>
>>>   	rcu_check_gp_kthread_starvation();
>>>
>>> +	trace_rcu_stall_warning(rcu_state.name, TPS("StallDetected"));
>>>   	panic_on_rcu_stall();
>>>
>>>   	rcu_force_quiescent_state();  /* Kick them all. */
>>> @@ -575,6 +576,7 @@ static void print_cpu_stall(unsigned long gps)
>>>   			   jiffies + 3 * rcu_jiffies_till_stall_check() + 3);
>>>   	raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
>>>
>>> +	trace_rcu_stall_warning(rcu_state.name, TPS("SelfDetected"));
>>>   	panic_on_rcu_stall();
>>>
>>>   	/*
>>> --
>>> 2.17.1
>>>
> 

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member of the Code Aurora Forum, hosted by The Linux Foundation

  reply	other threads:[~2021-02-17 18:19 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20210215090241epcas1p17b1319d38de5a09a9d65a06ebf936866@epcas1p1.samsung.com>
2021-02-15  8:53 ` [PATCH] rcu/tree: Add a trace event for RCU stall warnings Sangmoon Kim
2021-02-16 17:50   ` Paul E. McKenney
2021-02-17 13:49     ` Sangmoon Kim
2021-02-17 18:17       ` Neeraj Upadhyay [this message]
2021-02-18 12:52         ` Sangmoon Kim
2021-02-18 14:17           ` Mathieu Desnoyers
2021-02-18 15:06             ` Paul E. McKenney
2021-02-18 15:50               ` Mathieu Desnoyers
2021-02-18 16:58                 ` Uladzislau Rezki
2021-02-18 17:24                   ` Mathieu Desnoyers
2021-02-18 18:43                     ` Uladzislau Rezki
2021-02-18 17:00                 ` Paul E. McKenney
2021-02-18 17:56                   ` Mathieu Desnoyers
2021-02-18 18:13                     ` Paul E. McKenney
2021-02-18 18:24                   ` Steven Rostedt
2021-02-18 18:59                     ` Paul E. McKenney
2021-02-22  8:25                       ` Sangmoon Kim
2021-02-24  9:18                         ` Neeraj Upadhyay
2021-02-24 15:17                           ` Sangmoon Kim
2021-02-25  4:06                             ` [PATCH v2] " Sangmoon Kim
2021-02-28 19:47                               ` Uladzislau Rezki
2021-03-02 11:55                                 ` [PATCH v3] " Sangmoon Kim
2021-03-02 17:04                                   ` Neeraj Upadhyay
2021-03-02 19:20                                     ` 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=bf80e296-14bf-6f36-8952-416829d30e5a@codeaurora.org \
    --to=neeraju@codeaurora.org \
    --cc=jiangshanlai@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=josh@joshtriplett.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=paulmck@kernel.org \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=sangmoon.kim@samsung.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