Restartable Sequences "RSEQ" Support Returning To GNU C Library

[phoronix]

Phoronix: Restartable Sequences "RSEQ" Support Returning To GNU C Library

Back in 2018 for the Linux 4.18 kernel was introducing the Restartable Sequences system call for allowing faster user-space operations on per-CPU data. By avoiding atomic operations in cases like incrementing per-CPU counters, modifying per-CPU spinlocks, reading/writing to per-CPU ring buffers, and similar, Restartable Sequences can provide a performance advantage. The GNU C Library is landing its revised support for making use of this system call...

https://www.phoronix.com/scan.php?page=news_item&px=Glibc-RSEQ-Returns-2021

[coder]

So, I looked at sys/rseq.h, but it doesn't seem much like something that's exposed for applications to use. Am I correct in understanding that the purpose of this development is mainly to optimize some existing glibc functions?

[compudj]

So, I looked at sys/rseq.h, but it doesn't seem much like something that's exposed for applications to use. Am I correct in understanding that the purpose of this development is mainly to optimize some existing glibc functions?

Thanks for your question. I am Mathieu Desnoyers, maintainer of the rseq system call in the Linux kernel. Wiring up the rseq system call at the glibc level is required to ensure it can be used by the entire Linux ecosystem (applications and libraries). Now the tricky user-space bits helping applications and libraries make use of rseq are not currently in glibc, and there are no short-term plans to integrate these at the moment. I've created a library called "librseq" (currently in active development, not released officially yet) which implements a higher-level API on top of rseq. See https://git.kernel.org/pub/scm/libs/...q/librseq.git/ . Note that I need to update this project following the recent integration of rseq into glibc.

[coder]

Thanks for the reply.

Note that I need to update this project following the recent integration of rseq into glibc.

In the article, I noticed a remark about disabling glibc's rseq-tie in. Presumably, your library would need to do that? If it does, will you be able to support existing glibc functionality utilizing it, via somehow chaining to it?

[compudj]

Thanks for the reply.


In the article, I noticed a remark about disabling glibc's rseq-tie in. Presumably, your library would need to do that? If it does, will you be able to support existing glibc functionality utilizing it, via somehow chaining to it?

Actually, my short-term plan is to focus librseq's role on the high-level rseq API, leaving the task of rseq registration and ownership to libc (which has been my intent from the beginning). Therefore, my plans are to rework librseq to make it depend on glibc's rseq support, and maybe introduce a separate helper library (within the same librseq project) which would mimic glibc's rseq ABIs through an IE-model TLS.