1CONFIG_RCU_TRACE debugfs Files and Formats 2 3 4The rcutree and rcutiny implementations of RCU provide debugfs trace 5output that summarizes counters and state. This information is useful for 6debugging RCU itself, and can sometimes also help to debug abuses of RCU. 7The following sections describe the debugfs files and formats, first 8for rcutree and next for rcutiny. 9 10 11CONFIG_TREE_RCU and CONFIG_TREE_PREEMPT_RCU debugfs Files and Formats 12 13These implementations of RCU provides five debugfs files under the 14top-level directory RCU: rcu/rcudata (which displays fields in struct 15rcu_data), rcu/rcudata.csv (which is a .csv spreadsheet version of 16rcu/rcudata), rcu/rcugp (which displays grace-period counters), 17rcu/rcuhier (which displays the struct rcu_node hierarchy), and 18rcu/rcu_pending (which displays counts of the reasons that the 19rcu_pending() function decided that there was core RCU work to do). 20 21The output of "cat rcu/rcudata" looks as follows: 22 23rcu_sched: 24 0 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=10951/1 dn=0 df=1101 of=0 ri=36 ql=0 b=10 25 1 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=16117/1 dn=0 df=1015 of=0 ri=0 ql=0 b=10 26 2 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=1445/1 dn=0 df=1839 of=0 ri=0 ql=0 b=10 27 3 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=6681/1 dn=0 df=1545 of=0 ri=0 ql=0 b=10 28 4 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=1003/1 dn=0 df=1992 of=0 ri=0 ql=0 b=10 29 5 c=17829 g=17830 pq=1 pqc=17829 qp=1 dt=3887/1 dn=0 df=3331 of=0 ri=4 ql=2 b=10 30 6 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=859/1 dn=0 df=3224 of=0 ri=0 ql=0 b=10 31 7 c=17829 g=17830 pq=0 pqc=17829 qp=1 dt=3761/1 dn=0 df=1818 of=0 ri=0 ql=2 b=10 32rcu_bh: 33 0 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=10951/1 dn=0 df=0 of=0 ri=0 ql=0 b=10 34 1 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=16117/1 dn=0 df=13 of=0 ri=0 ql=0 b=10 35 2 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=1445/1 dn=0 df=15 of=0 ri=0 ql=0 b=10 36 3 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=6681/1 dn=0 df=9 of=0 ri=0 ql=0 b=10 37 4 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=1003/1 dn=0 df=15 of=0 ri=0 ql=0 b=10 38 5 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=3887/1 dn=0 df=15 of=0 ri=0 ql=0 b=10 39 6 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=859/1 dn=0 df=15 of=0 ri=0 ql=0 b=10 40 7 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=3761/1 dn=0 df=15 of=0 ri=0 ql=0 b=10 41 42The first section lists the rcu_data structures for rcu_sched, the second 43for rcu_bh. Note that CONFIG_TREE_PREEMPT_RCU kernels will have an 44additional section for rcu_preempt. Each section has one line per CPU, 45or eight for this 8-CPU system. The fields are as follows: 46 47o The number at the beginning of each line is the CPU number. 48 CPUs numbers followed by an exclamation mark are offline, 49 but have been online at least once since boot. There will be 50 no output for CPUs that have never been online, which can be 51 a good thing in the surprisingly common case where NR_CPUS is 52 substantially larger than the number of actual CPUs. 53 54o "c" is the count of grace periods that this CPU believes have 55 completed. CPUs in dynticks idle mode may lag quite a ways 56 behind, for example, CPU 4 under "rcu_sched" above, which has 57 slept through the past 25 RCU grace periods. It is not unusual 58 to see CPUs lagging by thousands of grace periods. 59 60o "g" is the count of grace periods that this CPU believes have 61 started. Again, CPUs in dynticks idle mode may lag behind. 62 If the "c" and "g" values are equal, this CPU has already 63 reported a quiescent state for the last RCU grace period that 64 it is aware of, otherwise, the CPU believes that it owes RCU a 65 quiescent state. 66 67o "pq" indicates that this CPU has passed through a quiescent state 68 for the current grace period. It is possible for "pq" to be 69 "1" and "c" different than "g", which indicates that although 70 the CPU has passed through a quiescent state, either (1) this 71 CPU has not yet reported that fact, (2) some other CPU has not 72 yet reported for this grace period, or (3) both. 73 74o "pqc" indicates which grace period the last-observed quiescent 75 state for this CPU corresponds to. This is important for handling 76 the race between CPU 0 reporting an extended dynticks-idle 77 quiescent state for CPU 1 and CPU 1 suddenly waking up and 78 reporting its own quiescent state. If CPU 1 was the last CPU 79 for the current grace period, then the CPU that loses this race 80 will attempt to incorrectly mark CPU 1 as having checked in for 81 the next grace period! 82 83o "qp" indicates that RCU still expects a quiescent state from 84 this CPU. 85 86o "dt" is the current value of the dyntick counter that is incremented 87 when entering or leaving dynticks idle state, either by the 88 scheduler or by irq. The number after the "/" is the interrupt 89 nesting depth when in dyntick-idle state, or one greater than 90 the interrupt-nesting depth otherwise. 91 92 This field is displayed only for CONFIG_NO_HZ kernels. 93 94o "dn" is the current value of the dyntick counter that is incremented 95 when entering or leaving dynticks idle state via NMI. If both 96 the "dt" and "dn" values are even, then this CPU is in dynticks 97 idle mode and may be ignored by RCU. If either of these two 98 counters is odd, then RCU must be alert to the possibility of 99 an RCU read-side critical section running on this CPU. 100 101 This field is displayed only for CONFIG_NO_HZ kernels. 102 103o "df" is the number of times that some other CPU has forced a 104 quiescent state on behalf of this CPU due to this CPU being in 105 dynticks-idle state. 106 107 This field is displayed only for CONFIG_NO_HZ kernels. 108 109o "of" is the number of times that some other CPU has forced a 110 quiescent state on behalf of this CPU due to this CPU being 111 offline. In a perfect world, this might neve happen, but it 112 turns out that offlining and onlining a CPU can take several grace 113 periods, and so there is likely to be an extended period of time 114 when RCU believes that the CPU is online when it really is not. 115 Please note that erring in the other direction (RCU believing a 116 CPU is offline when it is really alive and kicking) is a fatal 117 error, so it makes sense to err conservatively. 118 119o "ri" is the number of times that RCU has seen fit to send a 120 reschedule IPI to this CPU in order to get it to report a 121 quiescent state. 122 123o "ql" is the number of RCU callbacks currently residing on 124 this CPU. This is the total number of callbacks, regardless 125 of what state they are in (new, waiting for grace period to 126 start, waiting for grace period to end, ready to invoke). 127 128o "b" is the batch limit for this CPU. If more than this number 129 of RCU callbacks is ready to invoke, then the remainder will 130 be deferred. 131 132o "ci" is the number of RCU callbacks that have been invoked for 133 this CPU. Note that ci+ql is the number of callbacks that have 134 been registered in absence of CPU-hotplug activity. 135 136o "co" is the number of RCU callbacks that have been orphaned due to 137 this CPU going offline. These orphaned callbacks have been moved 138 to an arbitrarily chosen online CPU. 139 140o "ca" is the number of RCU callbacks that have been adopted due to 141 other CPUs going offline. Note that ci+co-ca+ql is the number of 142 RCU callbacks registered on this CPU. 143 144There is also an rcu/rcudata.csv file with the same information in 145comma-separated-variable spreadsheet format. 146 147 148The output of "cat rcu/rcugp" looks as follows: 149 150rcu_sched: completed=33062 gpnum=33063 151rcu_bh: completed=464 gpnum=464 152 153Again, this output is for both "rcu_sched" and "rcu_bh". Note that 154kernels built with CONFIG_TREE_PREEMPT_RCU will have an additional 155"rcu_preempt" line. The fields are taken from the rcu_state structure, 156and are as follows: 157 158o "completed" is the number of grace periods that have completed. 159 It is comparable to the "c" field from rcu/rcudata in that a 160 CPU whose "c" field matches the value of "completed" is aware 161 that the corresponding RCU grace period has completed. 162 163o "gpnum" is the number of grace periods that have started. It is 164 comparable to the "g" field from rcu/rcudata in that a CPU 165 whose "g" field matches the value of "gpnum" is aware that the 166 corresponding RCU grace period has started. 167 168 If these two fields are equal (as they are for "rcu_bh" above), 169 then there is no grace period in progress, in other words, RCU 170 is idle. On the other hand, if the two fields differ (as they 171 do for "rcu_sched" above), then an RCU grace period is in progress. 172 173 174The output of "cat rcu/rcuhier" looks as follows, with very long lines: 175 176c=6902 g=6903 s=2 jfq=3 j=72c7 nfqs=13142/nfqsng=0(13142) fqlh=6 1771/1 .>. 0:127 ^0 1783/3 .>. 0:35 ^0 0/0 .>. 36:71 ^1 0/0 .>. 72:107 ^2 0/0 .>. 108:127 ^3 1793/3f .>. 0:5 ^0 2/3 .>. 6:11 ^1 0/0 .>. 12:17 ^2 0/0 .>. 18:23 ^3 0/0 .>. 24:29 ^4 0/0 .>. 30:35 ^5 0/0 .>. 36:41 ^0 0/0 .>. 42:47 ^1 0/0 .>. 48:53 ^2 0/0 .>. 54:59 ^3 0/0 .>. 60:65 ^4 0/0 .>. 66:71 ^5 0/0 .>. 72:77 ^0 0/0 .>. 78:83 ^1 0/0 .>. 84:89 ^2 0/0 .>. 90:95 ^3 0/0 .>. 96:101 ^4 0/0 .>. 102:107 ^5 0/0 .>. 108:113 ^0 0/0 .>. 114:119 ^1 0/0 .>. 120:125 ^2 0/0 .>. 126:127 ^3 180rcu_bh: 181c=-226 g=-226 s=1 jfq=-5701 j=72c7 nfqs=88/nfqsng=0(88) fqlh=0 1820/1 .>. 0:127 ^0 1830/3 .>. 0:35 ^0 0/0 .>. 36:71 ^1 0/0 .>. 72:107 ^2 0/0 .>. 108:127 ^3 1840/3f .>. 0:5 ^0 0/3 .>. 6:11 ^1 0/0 .>. 12:17 ^2 0/0 .>. 18:23 ^3 0/0 .>. 24:29 ^4 0/0 .>. 30:35 ^5 0/0 .>. 36:41 ^0 0/0 .>. 42:47 ^1 0/0 .>. 48:53 ^2 0/0 .>. 54:59 ^3 0/0 .>. 60:65 ^4 0/0 .>. 66:71 ^5 0/0 .>. 72:77 ^0 0/0 .>. 78:83 ^1 0/0 .>. 84:89 ^2 0/0 .>. 90:95 ^3 0/0 .>. 96:101 ^4 0/0 .>. 102:107 ^5 0/0 .>. 108:113 ^0 0/0 .>. 114:119 ^1 0/0 .>. 120:125 ^2 0/0 .>. 126:127 ^3 185 186This is once again split into "rcu_sched" and "rcu_bh" portions, 187and CONFIG_TREE_PREEMPT_RCU kernels will again have an additional 188"rcu_preempt" section. The fields are as follows: 189 190o "c" is exactly the same as "completed" under rcu/rcugp. 191 192o "g" is exactly the same as "gpnum" under rcu/rcugp. 193 194o "s" is the "signaled" state that drives force_quiescent_state()'s 195 state machine. 196 197o "jfq" is the number of jiffies remaining for this grace period 198 before force_quiescent_state() is invoked to help push things 199 along. Note that CPUs in dyntick-idle mode throughout the grace 200 period will not report on their own, but rather must be check by 201 some other CPU via force_quiescent_state(). 202 203o "j" is the low-order four hex digits of the jiffies counter. 204 Yes, Paul did run into a number of problems that turned out to 205 be due to the jiffies counter no longer counting. Why do you ask? 206 207o "nfqs" is the number of calls to force_quiescent_state() since 208 boot. 209 210o "nfqsng" is the number of useless calls to force_quiescent_state(), 211 where there wasn't actually a grace period active. This can 212 happen due to races. The number in parentheses is the difference 213 between "nfqs" and "nfqsng", or the number of times that 214 force_quiescent_state() actually did some real work. 215 216o "fqlh" is the number of calls to force_quiescent_state() that 217 exited immediately (without even being counted in nfqs above) 218 due to contention on ->fqslock. 219 220o Each element of the form "1/1 0:127 ^0" represents one struct 221 rcu_node. Each line represents one level of the hierarchy, from 222 root to leaves. It is best to think of the rcu_data structures 223 as forming yet another level after the leaves. Note that there 224 might be either one, two, or three levels of rcu_node structures, 225 depending on the relationship between CONFIG_RCU_FANOUT and 226 CONFIG_NR_CPUS. 227 228 o The numbers separated by the "/" are the qsmask followed 229 by the qsmaskinit. The qsmask will have one bit 230 set for each entity in the next lower level that 231 has not yet checked in for the current grace period. 232 The qsmaskinit will have one bit for each entity that is 233 currently expected to check in during each grace period. 234 The value of qsmaskinit is assigned to that of qsmask 235 at the beginning of each grace period. 236 237 For example, for "rcu_sched", the qsmask of the first 238 entry of the lowest level is 0x14, meaning that we 239 are still waiting for CPUs 2 and 4 to check in for the 240 current grace period. 241 242 o The characters separated by the ">" indicate the state 243 of the blocked-tasks lists. A "T" preceding the ">" 244 indicates that at least one task blocked in an RCU 245 read-side critical section blocks the current grace 246 period, while a "." preceding the ">" indicates otherwise. 247 The character following the ">" indicates similarly for 248 the next grace period. A "T" should appear in this 249 field only for rcu-preempt. 250 251 o The numbers separated by the ":" are the range of CPUs 252 served by this struct rcu_node. This can be helpful 253 in working out how the hierarchy is wired together. 254 255 For example, the first entry at the lowest level shows 256 "0:5", indicating that it covers CPUs 0 through 5. 257 258 o The number after the "^" indicates the bit in the 259 next higher level rcu_node structure that this 260 rcu_node structure corresponds to. 261 262 For example, the first entry at the lowest level shows 263 "^0", indicating that it corresponds to bit zero in 264 the first entry at the middle level. 265 266 267The output of "cat rcu/rcu_pending" looks as follows: 268 269rcu_sched: 270 0 np=255892 qsp=53936 rpq=85 cbr=0 cng=14417 gpc=10033 gps=24320 nf=6445 nn=146741 271 1 np=261224 qsp=54638 rpq=33 cbr=0 cng=25723 gpc=16310 gps=2849 nf=5912 nn=155792 272 2 np=237496 qsp=49664 rpq=23 cbr=0 cng=2762 gpc=45478 gps=1762 nf=1201 nn=136629 273 3 np=236249 qsp=48766 rpq=98 cbr=0 cng=286 gpc=48049 gps=1218 nf=207 nn=137723 274 4 np=221310 qsp=46850 rpq=7 cbr=0 cng=26 gpc=43161 gps=4634 nf=3529 nn=123110 275 5 np=237332 qsp=48449 rpq=9 cbr=0 cng=54 gpc=47920 gps=3252 nf=201 nn=137456 276 6 np=219995 qsp=46718 rpq=12 cbr=0 cng=50 gpc=42098 gps=6093 nf=4202 nn=120834 277 7 np=249893 qsp=49390 rpq=42 cbr=0 cng=72 gpc=38400 gps=17102 nf=41 nn=144888 278rcu_bh: 279 0 np=146741 qsp=1419 rpq=6 cbr=0 cng=6 gpc=0 gps=0 nf=2 nn=145314 280 1 np=155792 qsp=12597 rpq=3 cbr=0 cng=0 gpc=4 gps=8 nf=3 nn=143180 281 2 np=136629 qsp=18680 rpq=1 cbr=0 cng=0 gpc=7 gps=6 nf=0 nn=117936 282 3 np=137723 qsp=2843 rpq=0 cbr=0 cng=0 gpc=10 gps=7 nf=0 nn=134863 283 4 np=123110 qsp=12433 rpq=0 cbr=0 cng=0 gpc=4 gps=2 nf=0 nn=110671 284 5 np=137456 qsp=4210 rpq=1 cbr=0 cng=0 gpc=6 gps=5 nf=0 nn=133235 285 6 np=120834 qsp=9902 rpq=2 cbr=0 cng=0 gpc=6 gps=3 nf=2 nn=110921 286 7 np=144888 qsp=26336 rpq=0 cbr=0 cng=0 gpc=8 gps=2 nf=0 nn=118542 287 288As always, this is once again split into "rcu_sched" and "rcu_bh" 289portions, with CONFIG_TREE_PREEMPT_RCU kernels having an additional 290"rcu_preempt" section. The fields are as follows: 291 292o "np" is the number of times that __rcu_pending() has been invoked 293 for the corresponding flavor of RCU. 294 295o "qsp" is the number of times that the RCU was waiting for a 296 quiescent state from this CPU. 297 298o "rpq" is the number of times that the CPU had passed through 299 a quiescent state, but not yet reported it to RCU. 300 301o "cbr" is the number of times that this CPU had RCU callbacks 302 that had passed through a grace period, and were thus ready 303 to be invoked. 304 305o "cng" is the number of times that this CPU needed another 306 grace period while RCU was idle. 307 308o "gpc" is the number of times that an old grace period had 309 completed, but this CPU was not yet aware of it. 310 311o "gps" is the number of times that a new grace period had started, 312 but this CPU was not yet aware of it. 313 314o "nf" is the number of times that this CPU suspected that the 315 current grace period had run for too long, and thus needed to 316 be forced. 317 318 Please note that "forcing" consists of sending resched IPIs 319 to holdout CPUs. If that CPU really still is in an old RCU 320 read-side critical section, then we really do have to wait for it. 321 The assumption behing "forcing" is that the CPU is not still in 322 an old RCU read-side critical section, but has not yet responded 323 for some other reason. 324 325o "nn" is the number of times that this CPU needed nothing. Alert 326 readers will note that the rcu "nn" number for a given CPU very 327 closely matches the rcu_bh "np" number for that same CPU. This 328 is due to short-circuit evaluation in rcu_pending(). 329 330 331CONFIG_TINY_RCU and CONFIG_TINY_PREEMPT_RCU debugfs Files and Formats 332 333These implementations of RCU provides a single debugfs file under the 334top-level directory RCU, namely rcu/rcudata, which displays fields in 335rcu_bh_ctrlblk, rcu_sched_ctrlblk and, for CONFIG_TINY_PREEMPT_RCU, 336rcu_preempt_ctrlblk. 337 338The output of "cat rcu/rcudata" is as follows: 339 340rcu_preempt: qlen=24 gp=1097669 g197/p197/c197 tasks=... 341 ttb=. btg=no ntb=184 neb=0 nnb=183 j=01f7 bt=0274 342 normal balk: nt=1097669 gt=0 bt=371 b=0 ny=25073378 nos=0 343 exp balk: bt=0 nos=0 344rcu_sched: qlen: 0 345rcu_bh: qlen: 0 346 347This is split into rcu_preempt, rcu_sched, and rcu_bh sections, with the 348rcu_preempt section appearing only in CONFIG_TINY_PREEMPT_RCU builds. 349The last three lines of the rcu_preempt section appear only in 350CONFIG_RCU_BOOST kernel builds. The fields are as follows: 351 352o "qlen" is the number of RCU callbacks currently waiting either 353 for an RCU grace period or waiting to be invoked. This is the 354 only field present for rcu_sched and rcu_bh, due to the 355 short-circuiting of grace period in those two cases. 356 357o "gp" is the number of grace periods that have completed. 358 359o "g197/p197/c197" displays the grace-period state, with the 360 "g" number being the number of grace periods that have started 361 (mod 256), the "p" number being the number of grace periods 362 that the CPU has responded to (also mod 256), and the "c" 363 number being the number of grace periods that have completed 364 (once again mode 256). 365 366 Why have both "gp" and "g"? Because the data flowing into 367 "gp" is only present in a CONFIG_RCU_TRACE kernel. 368 369o "tasks" is a set of bits. The first bit is "T" if there are 370 currently tasks that have recently blocked within an RCU 371 read-side critical section, the second bit is "N" if any of the 372 aforementioned tasks are blocking the current RCU grace period, 373 and the third bit is "E" if any of the aforementioned tasks are 374 blocking the current expedited grace period. Each bit is "." 375 if the corresponding condition does not hold. 376 377o "ttb" is a single bit. It is "B" if any of the blocked tasks 378 need to be priority boosted and "." otherwise. 379 380o "btg" indicates whether boosting has been carried out during 381 the current grace period, with "exp" indicating that boosting 382 is in progress for an expedited grace period, "no" indicating 383 that boosting has not yet started for a normal grace period, 384 "begun" indicating that boosting has bebug for a normal grace 385 period, and "done" indicating that boosting has completed for 386 a normal grace period. 387 388o "ntb" is the total number of tasks subjected to RCU priority boosting 389 periods since boot. 390 391o "neb" is the number of expedited grace periods that have had 392 to resort to RCU priority boosting since boot. 393 394o "nnb" is the number of normal grace periods that have had 395 to resort to RCU priority boosting since boot. 396 397o "j" is the low-order 12 bits of the jiffies counter in hexadecimal. 398 399o "bt" is the low-order 12 bits of the value that the jiffies counter 400 will have at the next time that boosting is scheduled to begin. 401 402o In the line beginning with "normal balk", the fields are as follows: 403 404 o "nt" is the number of times that the system balked from 405 boosting because there were no blocked tasks to boost. 406 Note that the system will balk from boosting even if the 407 grace period is overdue when the currently running task 408 is looping within an RCU read-side critical section. 409 There is no point in boosting in this case, because 410 boosting a running task won't make it run any faster. 411 412 o "gt" is the number of times that the system balked 413 from boosting because, although there were blocked tasks, 414 none of them were preventing the current grace period 415 from completing. 416 417 o "bt" is the number of times that the system balked 418 from boosting because boosting was already in progress. 419 420 o "b" is the number of times that the system balked from 421 boosting because boosting had already completed for 422 the grace period in question. 423 424 o "ny" is the number of times that the system balked from 425 boosting because it was not yet time to start boosting 426 the grace period in question. 427 428 o "nos" is the number of times that the system balked from 429 boosting for inexplicable ("not otherwise specified") 430 reasons. This can actually happen due to races involving 431 increments of the jiffies counter. 432 433o In the line beginning with "exp balk", the fields are as follows: 434 435 o "bt" is the number of times that the system balked from 436 boosting because there were no blocked tasks to boost. 437 438 o "nos" is the number of times that the system balked from 439 boosting for inexplicable ("not otherwise specified") 440 reasons. 441