MDEV-15053 reduced some buf_pool.mutex contention, shifting some contention to the buf_pool.page_hash latches. MDEV-22850 removed some genuine contention on the latches by reducing the X-latch hold time.
But, based on earlier perf record analysis we seem to have some spurious contention on concurrent S-latch requests. I believe that this is due to the spin loop rw_lock_lock_word_decr() that rw_lock_s_lock() is executing.
Spurious S-latch conflicts could be addressed by implementing a bare-bones variant of rw-locks using std::atomic::fetch_add() for the S-latch and compare_exchange_strong() for the X-latch acquisition. This variant would not need to support any recursive latches at all.
As far as I understand, only dict_index_t::lock, buf_block_t::lock, fil_space_t::latch, dict_sys.latch, purge_sys.latch may truly require some additional ‘bells and whistles’, such as recursive X-locks or SX-locks, instrumentation, and event-based wakeup of waiting requests.
Most other types of InnoDB rw-locks should be held for extremely short durations only, and we might best implement both S and X latch acquisition with simple spin loops (inlined atomic operation possibly followed by a subroutine call for the spin loop).