Hello, Joel, In case you are -seriously- interested... ;-) Thanx, Paul rcu_nocbs= Adding a CPU to this list offloads RCU callback invocation from that CPU's softirq handler to a kthread. In big.LITTLE systems, this kthread can be placed on a LITTLE CPU, which has been demonstrated to save significant energy in benchmarks. http://www.rdrop.com/users/paulmck/realtime/paper/AMPenergy.2013.04.19a.pdf nohz_full= Any CPU specified by this boot parameter is handled as if it was specified by rcu_nocbs=. rcutree.jiffies_till_first_fqs= Increasing this will decrease wakeup frequency to the grace-period kthread for the first FQS scan. And increase grace-period latency. rcutree.jiffies_till_next_fqs= Ditto, but for the second and subsequent FQS scans. My guess is that neither of these makes much difference. But if they do, maybe some sort of backoff scheme for FQS scans? rcutree.jiffies_till_sched_qs= Increasing this will delay RCU's getting excited about CPUs and tasks not responding with quiescent states. This excitement can cause extra overhead. No idea whether adjusting this would help. But if you increase rcutree.jiffies_till_first_fqs or rcutree.jiffies_till_next_fqs, you might need to increase this one accordingly. rcutree.qovld= Increasing this will increase the grace-period duration at which RCU starts sending IPIs, thus perhaps reducing the total number of IPIs that RCU sends. The destination CPUs are unlikely to be idle, so it is not clear to me that this would help much. But perhaps I am wrong about them being mostly non-idle, who knows? rcupdate.rcu_cpu_stall_timeout= If you get overly zealous about the earlier kernel boot parameters, you might need to increase this one as well. Or instead use the rcupdate.rcu_cpu_stall_suppress= kernel boot parameter to suppress RCU CPU stall warnings entirely. rcutree.rcu_nocb_gp_stride= Increasing this might reduce grace-period work somewhat. I don't see why a (say) 16-CPU system really needs to have more than one rcuog kthread, so if this does help it might be worthwhile setting a lower limit to this kernel parameter. rcutree.rcu_idle_gp_delay= (Only CONFIG_RCU_FAST_NO_HZ=y kernels.) This defaults to four jiffies on the theory that grace periods tend to last about that long. If grace periods tend to take longer, then it makes a lot of sense to increase this. And maybe battery-powered devices would rather have it be about 2x or 3x the expected grace-period duration, who knows? I would keep it to a power of two, but the code should work with other numbers. Except that I don't know that this has ever been tested. ;-) srcutree.exp_holdoff= Increasing this decreases the number of SRCU grace periods that are treated as expedited. But you have to have closely-spaced SRCU grace periods for this to matter. (These do happen at least sometimes because I added this only because someone complained about the performance regression from the earlier non-tree SRCU.) rcupdate.rcu_task_ipi_delay= This kernel parameter delays sending IPIs for RCU Tasks Trace, which is used by sleepable BPF programs. Increasing it can reduce overhead, but can also increase the latency of removing sleepable BPF programs. rcupdate.rcu_task_stall_timeout= If you slow down RCU Tasks Trace too much, you may need this. But then again, the default 10-minute value should suffice. CONFIG_RCU_FAST_NO_HZ=y This only has effect on CPUs not specified by rcu_nocbs, and thus might be useful on systems that offload RCU callbacks only on some of the CPUs. For example, a big.LITTLE system might offload only the big CPUs. This Kconfig option reduces the frequency of timer interrupts (and thus of RCU-related softirq processing) on idle CPUs. This has been shown to save significant energy in benchmarks: http://www.rdrop.com/users/paulmck/realtime/paper/AMPenergy.2013.04.19a.pdf CONFIG_RCU_STRICT_GRACE_PERIOD=y This works hard (as in burns CPU) to sharply reduce grace-period latency. The effect is probably to greatly increase power consumption, but there might well be workloads where the shorter grace periods more than make up for the extra CPU time. Or not. CONFIG_HZ= Reducing the scheduler-clock interrupt frequency has the opposite effect, namely of increasing RCU grace-period latency, but while also reducing RCU's CPU utilization. CONFIG_TASKS_TRACE_RCU_READ_MB=y Reduce the need to IPI RCU Tasks Trace holdout tasks, but at the expense of an increase in to/from idle overhead. This Kconfig option also slows down the rate at which RCU Tasks Trace polls for holdout tasks. This polling rate cannot be separately specified, but if changing the initial source-code values of either rcu_tasks_trace.gp_sleep or rcu_tasks_trace.init_fract proves useful, kernel boot parameters could be created. That said, automatic initialization heuristics are more convenient. When they work, anyway.