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
