Re: [PATCH 1/5] torture: Remove support for SRCU-lite

[Paul E. McKenney]

On Wed, Jun 25, 2025 at 05:05:47AM -0700, Christoph Hellwig wrote:
> On Tue, Jun 24, 2025 at 09:13:56AM -0700, Paul E. McKenney wrote:
> > Because SRCU-lite is being replaced by SRCU-fast, this commit removes
> > support for SRCU-lite from refscale.c.
> 
> Please explain how they different and why one is a good enough (or
> even better?) replacement for the other.

Ah, good point, thank you!

How about if I add this to the cover letter?

	Both SRCU-lite and SRCU-fast provide faster readers by dropping
	the smp_mb() call from their lock and unlock primitives.
	The price of this is a pair of added RCU grace periods during
	the SRCU grace period.

	SRCU-fast also adds NMI safety for architectures that have
	NMIs but do not have NMI-safe per-CPU operations.  In addition,
	srcu_read_lock_fast() returns a per-CPU pointer rather than an
	integer, which provides a further speedup compared to SRCU-lite
	by getting rid of array-index calculations.

	There is a trivial mapping from the SRCU-lite API to that
	of SRCU-fast, so we do not expect any transition issues.
	In addition, while SRCU-lite remains in the kernel, checkpatch.pl
	will warn about added SRCU-lite use cases.

	Further read-side speedups are possible, but they amount to only
	about half a nanosecond out of about two nanoseconds (measured on
	my x86 laptop), and they might require some changes to existing
	SRCU code.  These changes are trivial, but we need to see a
	solid need for the additional performance before inconveniencing
	existing users.

							Thanx, Paul