linux-kernel - Re: [PATCH rcu 0/18] RCU no-CBs CPU updates for v5.17

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20211202180144.GN641268@paulmck-ThinkPad-P17-Gen-1>
Date:   Thu, 2 Dec 2021 10:01:44 -0800
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Yury Norov <yury.norov@...il.com>
Cc:     rcu@...r.kernel.org, linux-kernel@...r.kernel.org,
        kernel-team@...com, mingo@...nel.org, jiangshanlai@...il.com,
        akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
        josh@...htriplett.org, tglx@...utronix.de, peterz@...radead.org,
        rostedt@...dmis.org, dhowells@...hat.com, edumazet@...gle.com,
        fweisbec@...il.com, oleg@...hat.com, joel@...lfernandes.org
Subject: Re: [PATCH rcu 0/18] RCU no-CBs CPU updates for v5.17

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.