rcu: document TINY_RCU and TINY_PREEMPT_RCU tracing.

CONFIG_RCU_TRACE debugfs Files and Formats

CONFIG_RCU_TRACE debugfs Files and Formats

The rcutree implementation of RCU provides debugfs trace output that

The rcutree and rcutiny implementations of RCU provide debugfs trace

summarizes counters and state.  This information is useful for debugging

output that summarizes counters and state.  This information is useful for

RCU itself, and can sometimes also help to debug abuses of RCU.

debugging RCU itself, and can sometimes also help to debug abuses of RCU.

The following sections describe the debugfs files and formats.

The following sections describe the debugfs files and formats, first

for rcutree and next for rcutiny.

Hierarchical RCU debugfs Files and Formats

CONFIG_TREE_RCU and CONFIG_TREE_PREEMPT_RCU debugfs Files and Formats

This implementation of RCU provides three debugfs files under the

These implementations of RCU provides five debugfs files under the

top-level directory RCU: rcu/rcudata (which displays fields in struct

top-level directory RCU: rcu/rcudata (which displays fields in struct

rcu_data), rcu/rcugp (which displays grace-period counters), and

rcu_data), rcu/rcudata.csv (which is a .csv spreadsheet version of

rcu/rcuhier (which displays the struct rcu_node hierarchy).

rcu/rcudata), rcu/rcugp (which displays grace-period counters),

rcu/rcuhier (which displays the struct rcu_node hierarchy), and

rcu/rcu_pending (which displays counts of the reasons that the

rcu_pending() function decided that there was core RCU work to do).

The output of "cat rcu/rcudata" looks as follows:

The output of "cat rcu/rcudata" looks as follows:

	readers will note that the rcu "nn" number for a given CPU very

	readers will note that the rcu "nn" number for a given CPU very

	closely matches the rcu_bh "np" number for that same CPU.  This

	closely matches the rcu_bh "np" number for that same CPU.  This

	is due to short-circuit evaluation in rcu_pending().

	is due to short-circuit evaluation in rcu_pending().

CONFIG_TINY_RCU and CONFIG_TINY_PREEMPT_RCU debugfs Files and Formats

These implementations of RCU provides a single debugfs file under the

top-level directory RCU, namely rcu/rcudata, which displays fields in

rcu_bh_ctrlblk, rcu_sched_ctrlblk and, for CONFIG_TINY_PREEMPT_RCU,

rcu_preempt_ctrlblk.

The output of "cat rcu/rcudata" is as follows:

rcu_preempt: qlen=24 gp=1097669 g197/p197/c197 tasks=...

             ttb=. btg=no ntb=184 neb=0 nnb=183 j=01f7 bt=0274

             normal balk: nt=1097669 gt=0 bt=371 b=0 ny=25073378 nos=0

             exp balk: bt=0 nos=0

rcu_sched: qlen: 0

rcu_bh: qlen: 0

This is split into rcu_preempt, rcu_sched, and rcu_bh sections, with the

rcu_preempt section appearing only in CONFIG_TINY_PREEMPT_RCU builds.

The last three lines of the rcu_preempt section appear only in

CONFIG_RCU_BOOST kernel builds.  The fields are as follows:

o	"qlen" is the number of RCU callbacks currently waiting either

	for an RCU grace period or waiting to be invoked.  This is the

	only field present for rcu_sched and rcu_bh, due to the

	short-circuiting of grace period in those two cases.

o	"gp" is the number of grace periods that have completed.

o	"g197/p197/c197" displays the grace-period state, with the

	"g" number being the number of grace periods that have started

	(mod 256), the "p" number being the number of grace periods

	that the CPU has responded to (also mod 256), and the "c"

	number being the number of grace periods that have completed

	(once again mode 256).

	Why have both "gp" and "g"?  Because the data flowing into

	"gp" is only present in a CONFIG_RCU_TRACE kernel.

o	"tasks" is a set of bits.  The first bit is "T" if there are

	currently tasks that have recently blocked within an RCU

	read-side critical section, the second bit is "N" if any of the

	aforementioned tasks are blocking the current RCU grace period,

	and the third bit is "E" if any of the aforementioned tasks are

	blocking the current expedited grace period.  Each bit is "."

	if the corresponding condition does not hold.

o	"ttb" is a single bit.  It is "B" if any of the blocked tasks

	need to be priority boosted and "." otherwise.

o	"btg" indicates whether boosting has been carried out during

	the current grace period, with "exp" indicating that boosting

	is in progress for an expedited grace period, "no" indicating

	that boosting has not yet started for a normal grace period,

	"begun" indicating that boosting has bebug for a normal grace

	period, and "done" indicating that boosting has completed for

	a normal grace period.

o	"ntb" is the total number of tasks subjected to RCU priority boosting

	periods since boot.

o	"neb" is the number of expedited grace periods that have had

	to resort to RCU priority boosting since boot.

o	"nnb" is the number of normal grace periods that have had

	to resort to RCU priority boosting since boot.

o	"j" is the low-order 12 bits of the jiffies counter in hexadecimal.

o	"bt" is the low-order 12 bits of the value that the jiffies counter

	will have at the next time that boosting is scheduled to begin.

o	In the line beginning with "normal balk", the fields are as follows:

	o	"nt" is the number of times that the system balked from

		boosting because there were no blocked tasks to boost.

		Note that the system will balk from boosting even if the

		grace period is overdue when the currently running task

		is looping within an RCU read-side critical section.

		There is no point in boosting in this case, because

		boosting a running task won't make it run any faster.

	o	"gt" is the number of times that the system balked

		from boosting because, although there were blocked tasks,

		none of them were preventing the current grace period

		from completing.

	o	"bt" is the number of times that the system balked

		from boosting because boosting was already in progress.

	o	"b" is the number of times that the system balked from

		boosting because boosting had already completed for

		the grace period in question.

	o	"ny" is the number of times that the system balked from

		boosting because it was not yet time to start boosting

		the grace period in question.

	o	"nos" is the number of times that the system balked from

		boosting for inexplicable ("not otherwise specified")

		reasons.  This can actually happen due to races involving

		increments of the jiffies counter.

o	In the line beginning with "exp balk", the fields are as follows:

	o	"bt" is the number of times that the system balked from

		boosting because there were no blocked tasks to boost.

	o	"nos" is the number of times that the system balked from

		 boosting for inexplicable ("not otherwise specified")

		 reasons.