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
