Pull the v3.5 RCU tree from Paul E. McKenney: 1) A set of improvements and fixes to the RCU_FAST_NO_HZ feature (with more on the way for 3.6). Posted to LKML: https://lkml.org/lkml/2012/4/23/324 (commits 1-3 and 5), https://lkml.org/lkml/2012/4/16/611 (commit 4), https://lkml.org/lkml/2012/4/30/390 (commit 6), and https://lkml.org/lkml/2012/5/4/410 (commit 7, combined with the other commits for the convenience of the tester). 2) Changes to make rcu_barrier() avoid disrupting execution of CPUs that have no RCU callbacks. Posted to LKML: https://lkml.org/lkml/2012/4/23/322. 3) A couple of commits that improve the efficiency of the interaction between preemptible RCU and the scheduler, these two being all that survived an abortive attempt to allow preemptible RCU's __rcu_read_lock() to be inlined. The full set was posted to LKML at https://lkml.org/lkml/2012/4/14/143, and the first and third patches of that set remain. 4) Lai Jiangshan's algorithmic implementation of SRCU, which includes call_srcu() and srcu_barrier(). A major feature of this new implementation is that synchronize_srcu() no longer disturbs the execution of other CPUs. This work is based on earlier implementations by Peter Zijlstra and Paul E. McKenney. Posted to LKML: https://lkml.org/lkml/2012/2/22/82. 5) A number of miscellaneous bug fixes and improvements which were posted to LKML at: https://lkml.org/lkml/2012/4/23/353 with subsequent updates posted to LKML.
Showing the changes to init (1 of 23 files). Show all
Unified · Split
| @@ -458,6 +458,33 @@ config RCU_FANOUT · 457 unmodified lines | ||
| 458 | 458 | Select a specific number if testing RCU itself. |
| 459 | 459 | Take the default if unsure. |
| 460 | 460 | |
| 461 | +config RCU_FANOUT_LEAF | |
| 462 | + int "Tree-based hierarchical RCU leaf-level fanout value" | |
| 463 | + range 2 RCU_FANOUT if 64BIT | |
| 464 | + range 2 RCU_FANOUT if !64BIT | |
| 465 | + depends on TREE_RCU || TREE_PREEMPT_RCU | |
| 466 | + default 16 | |
| 467 | + help | |
| 468 | + This option controls the leaf-level fanout of hierarchical | |
| 469 | + implementations of RCU, and allows trading off cache misses | |
| 470 | + against lock contention. Systems that synchronize their | |
| 471 | + scheduling-clock interrupts for energy-efficiency reasons will | |
| 472 | + want the default because the smaller leaf-level fanout keeps | |
| 473 | + lock contention levels acceptably low. Very large systems | |
| 474 | + (hundreds or thousands of CPUs) will instead want to set this | |
| 475 | + value to the maximum value possible in order to reduce the | |
| 476 | + number of cache misses incurred during RCU's grace-period | |
| 477 | + initialization. These systems tend to run CPU-bound, and thus | |
| 478 | + are not helped by synchronized interrupts, and thus tend to | |
| 479 | + skew them, which reduces lock contention enough that large | |
| 480 | + leaf-level fanouts work well. | |
| 481 | + | |
| 482 | + Select a specific number if testing RCU itself. | |
| 483 | + | |
| 484 | + Select the maximum permissible value for large systems. | |
| 485 | + | |
| 486 | + Take the default if unsure. | |
| 487 | + | |
| 461 | 488 | config RCU_FANOUT_EXACT |
| 462 | 489 | bool "Disable tree-based hierarchical RCU auto-balancing" |
| 463 | 490 | depends on TREE_RCU || TREE_PREEMPT_RCU |
| @@ -515,10 +542,25 @@ config RCU_BOOST_PRIO · 51 unmodified lines | ||
| 515 | 542 | depends on RCU_BOOST |
| 516 | 543 | default 1 |
| 517 | 544 | help |
| 518 | − This option specifies the real-time priority to which preempted | |
| 519 | − RCU readers are to be boosted. If you are working with CPU-bound | |
| 520 | − real-time applications, you should specify a priority higher then | |
| 521 | − the highest-priority CPU-bound application. | |
| 545 | + This option specifies the real-time priority to which long-term | |
| 546 | + preempted RCU readers are to be boosted. If you are working | |
| 547 | + with a real-time application that has one or more CPU-bound | |
| 548 | + threads running at a real-time priority level, you should set | |
| 549 | + RCU_BOOST_PRIO to a priority higher then the highest-priority | |
| 550 | + real-time CPU-bound thread. The default RCU_BOOST_PRIO value | |
| 551 | + of 1 is appropriate in the common case, which is real-time | |
| 552 | + applications that do not have any CPU-bound threads. | |
| 553 | + | |
| 554 | + Some real-time applications might not have a single real-time | |
| 555 | + thread that saturates a given CPU, but instead might have | |
| 556 | + multiple real-time threads that, taken together, fully utilize | |
| 557 | + that CPU. In this case, you should set RCU_BOOST_PRIO to | |
| 558 | + a priority higher than the lowest-priority thread that is | |
| 559 | + conspiring to prevent the CPU from running any non-real-time | |
| 560 | + tasks. For example, if one thread at priority 10 and another | |
| 561 | + thread at priority 5 are between themselves fully consuming | |
| 562 | + the CPU time on a given CPU, then RCU_BOOST_PRIO should be | |
| 563 | + set to priority 6 or higher. | |
| 522 | 564 | |
| 523 | 565 | Specify the real-time priority, or take the default if unsure. |
| 524 | 566 | |