On Wed, Dec 01, 2021 at 06:03:47PM -0800, Yury Norov wrote: > On Wed, Dec 01, 2021 at 04:28:48PM -0800, Paul E. McKenney wrote: > > Hello! > > ... > > > 17. Allow empty "rcu_nocbs" kernel parameter, courtesy of Frederic > > Weisbecker. > > ... > > > Note that #17 might be updated given some ongoing work by Yury Norov > > to support "none" for bitmaps, including the cpumask taken by the > > rcu_nocbs kernel-boot parameter. > > Hi Paul, > > This is the only work that is needed to support 'none': > > https://lkml.org/lkml/2021/11/24/2642 > > >From the last discussion, it's not clear is this 'none' needed or not. > If needed, I'll submit the patch. The question is whether rcu_nocbs= semantics like this are reasonable. In other words, will systems administrators be OK with the idea of differentiation between "rcu_nocbs=none" on the one hand and not specifying rcu_nocbs at all on the other. Thoughts? Thanx, Paul ------------------------------------------------------------------------ rcu_nocbs= [KNL] The argument is a cpu list, as described above. In kernels built with CONFIG_RCU_NOCB_CPU=y, enable the no-callback CPU mode, which prevents such CPUs' callbacks from being invoked in softirq context. Invocation of such CPUs' RCU callbacks will instead be offloaded to "rcuox/N" kthreads created for that purpose, where "x" is "p" for RCU-preempt, "s" for RCU-sched, and "g" for the kthreads that mediate grace periods; and "N" is the CPU number. This reduces OS jitter on the offloaded CPUs, which can be useful for HPC and real-time workloads. It can also improve energy efficiency, especially for asymmetric multiprocessors. The cpulist specifies which are to be set to no-callback mode from boot. In particular, "rcu_nocbs=none" specifies that no CPUs are in no-callback mode at boot, but that any of them can be offloaded at runtime. In contrast, in kernels that boot with no rcu_nocbs kernel boot parameter, CPUs are not only in no-callback mode at boot, but they remain that way throughout.
