I've started an upstream discussion:

Bringing rseq back into glibc
https://sourceware.org/pipermail/libc-alpha/2021-November/133221.html

I've posted patches:

[PATCH 0/5] Extensible rseq support for glibc
https://sourceware.org/pipermail/libc-alpha/2021-December/133656.html

The upstream patches have been integrated, and I believe we have fixed the regression.

Jeremy, would you be able to arrange for performance tests once we have a test build?

We are not quite ready to backport this because we need to teach valgrind about rseq first (bug 2030872).

valgrind is fixed, but criu is not, so this has to be opt-in for now, using the glibc.pthread.rseq tunable.

Yes, I will test it again, I had a testing setup over christmas.

Hi Jeremy,
sorry to bother you, any luck with the testing?
Thanks, Matej

Yah, I'm about to post a small benchmark set here. I've been running various sysbench/etc things over the past couple days on an ampere ultra, the gravaton plan hasn't managed to pan out yet (still in progress). Right now the general oltp results show a small uplift, but i'm now running the exact tests that the AST team used last year, so the results should be more noticeable. I'm planning on calling this done in the next ~day.

Well, I guess I continue to fail to identify that peak 20%+ uplift in memory/mysql/OLTP style workloads with this patch applied, I think the general OLTP uplift with the mysql specific patch was something like 3% and in some tests and I can see that. Or at least something along those lines since i'm not sure my tests are repeatable enough that 2-3% can be attributed to this patch vs lucky scheduling/memory placement/whatever.  Part of the problem may be some difference between mariadb as shipped with RHEL that i'm using, and the actual mysql originally used in the test environment. For sure there are system configuration/innodb tuning parameter differences that I can't reconcile simply because the code bases have diverged around numa tuning/etc.

I can keep banging on it, but really the core request was to fix sched_getcpu(), for which I can report with a hand rolled "am I still on the same CPU" loop the uplift is a pedestrian ~47X on an Altra. LoL. 

AKA, that much uplift can't help but show up in all sorts of places.

So, for purposes of closing this, I think the answer is overwhelmingly that its been fixed. OTOH, I'm not sure that I can say with confidence that there is a double digit % mariadb/OLTP uplift because of it, at this point.

Thanks. Was the mysql-specific patch inling the rseq access, by chance? Avoiding the sched_getcpu function call overhead?

We may have to export the GLIBC_2.35 symbols for interoperability purposes once we turn on rseq by default, and if we do that, mysql could switch back to inlining rseq access.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (new packages: glibc), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:3917

Yah, just as a FYI, the original testing was with a custom mysql patch, but it was also using a very custom test setup, using stored procedures and backing the DB with ram/etc. So lots of variables that individually could be affecting it.