Glibc's Usage Of Performance-Boosting "RSEQ" Is Still Coming Together

Introduced into the Linux 4.18 kernel back in June 2018 was the new RSEQ system call for "Restartable Sequences" to provide faster user-space operations on per-CPU data by avoiding atomic operations updates. Sadly, seeing user-space make use of RSEQ has been a slow process.

Restartable Sequences can make for faster querying of the current CPU number, incrementing per-CPU counters, modifying data protected by per-CPU spinlocks, writing/reading per-CPU ring buffers, and similar operations. One of the big potential users of RSEQ that we've been waiting to see its adoption on has been the GNU C Library (Glibc).

Benchmarks of RSEQ can yield dramatic improvements and last year was hope on getting RSEQ-backed function support into Glibc 2.31 but sadly that didn't pan out. But patch work has continued by the likes of Mathieu Desnoyers.

On Monday was the latest version of a Glibc patch for making use of RSEQ for sched_getcpu(), the call to determine the CPU core on which the calling thread is executing.

By making use of the RSEQ system call, the GNU C Library's sched_getcpu() can be 5.5x faster. Or if using an inline load of the CPU ID from __rseq_abi TLS is a 17.1x speed-up. Glibc would still fall-back to the existing behavior should it be on an older kernel without Restartable Sequences support.

Hopefully we'll see more RSEQ adoption within Glibc and elsewhere as the year progresses.