Bug#804857: linux: New feature: enable CONFIG_NO_HZ_FULL and CONFIG_RCU_NOCB_CPU/CONFIG_RCU_NOCB_CPU_NONE

[Salvatore Bonaccorso <carnil@debian.org>]

Control: tags -1 + moreinfo

On Wed, Oct 27, 2021 at 10:16:56AM +0200, Georg Müller wrote:
> > But for other configurations it is worse:
> > 
> > config NO_HZ_FULL
> >         bool "Full dynticks system (tickless)"
> > ...
> >          This is implemented at the expense of some overhead in user <-> kernel
> >          transitions: syscalls, exceptions and interrupts. Even when it's
> >          dynamically off.
> > 
> >          Say N.
> > 
> 
> 
> Upstream commit 176b8906 changed the description regarding NO_HZ_FULL:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=176b8906c399a170886ea4bad5b24763c6713d61
> 
> 
> > By default, without passing the nohz_full parameter, this behaves just
> > like NO_HZ_IDLE.
> >
> > If you're a distro say Y.

While this is changed, and distros encouraged to select it, selecting
this would enable both CONFIG_VIRT_CPU_ACCOUNTING_GEN and
CONFIG_RCU_NOCB_CPU.

For CONFIG_VIRT_CPU_ACCOUNTING_GEN

          Select this option to enable task and CPU time accounting on full
          dynticks systems. This accounting is implemented by watching every
          kernel-user boundaries using the context tracking subsystem.
          The accounting is thus performed at the expense of some significant
          overhead.

          For now this is only useful if you are working on the full
          dynticks subsystem development.

          If unsure, say N.

which indicates some significant overhead.

And for CONFIG_RCU_NOCB_CPU

          Use this option to reduce OS jitter for aggressive HPC or
          real-time workloads.  It can also be used to offload RCU
          callback invocation to energy-efficient CPUs in battery-powered
          asymmetric multiprocessors.  The price of this reduced jitter
          is that the overhead of call_rcu() increases and that some
          workloads will incur significant increases in context-switch
          rates.

          This option offloads callback invocation from the set of CPUs
          specified at boot time by the rcu_nocbs parameter.  For each
          such CPU, a kthread ("rcuox/N") will be created to invoke
          callbacks, where the "N" is the CPU being offloaded, and where
          the "x" is "p" for RCU-preempt (PREEMPTION kernels) and "s" for
          RCU-sched (!PREEMPTION kernels).  Nothing prevents this kthread
          from running on the specified CPUs, but (1) the kthreads may be
          preempted between each callback, and (2) affinity or cgroups can
          be used to force the kthreads to run on whatever set of CPUs is
          desired.

          Say Y here if you need reduced OS jitter, despite added overhead.
          Say N here if you are unsure.

Adding as well overhead.

Is this still to be considered true?

Regards,
Salvatore