MDEV-39040 log_sys.latch performance lost to PERFORMANCE_SCHEMA

[dr-m]

• The Jira issue number for this PR is: MDEV-39040

Description

log_sys.latch: Remove the PERFORMANCE_SCHEMA instrumentation. We already know that this is a very busy latch. All code paths where a shared log_sys.latch is being held should already be highly optimized. The few paths where an exclusive log_sys.latch is being held are known to be potentially problematic, but rare.

Release Notes

The PERFORMANCE_SCHEMA instrument wait/synch/rwlock/innodb/log_latch was removed.

How can this PR be tested?

On a quick Sysbench oltp_update_index run with

performance_schema_instrument=wait/synch/rwlock/%=on

I observed an 2.9% improvement on throughput. It could be more in other test scenarios.

Basing the PR against the correct MariaDB version

• This is a new feature or a refactoring, and the PR is based against the main branch.
• This is a bug fix, and the PR is based against the earliest maintained branch in which the bug can be reproduced.

PR quality check

• I checked the CODING_STANDARDS.md file and my PR conforms to this where appropriate.
• For any trivial modifications to the PR, I am ok with the reviewer making the changes themselves.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[iMineLink]

Compilation is broken with WITH_INNODB_EXTRA_DEBUG=ON, otherwise changes look good.
Maybe a comment could be left in the code explaining the reason of using srw_lock_low for the log_sys.latch, to ease reading?

[iMineLink]

It seems srw_lock_debug still has the PFS instrumentation which required the SRW_LOCK_CALL arguments, but those were removed.
Compiling with WITH_INNODB_EXTRA_DEBUG=ON gives similar errors:

/repos/server-10-11/storage/innobase/buf/buf0flu.cc: In member function ‘void log_t::write_checkpoint(lsn_t, lsn_t)’:
/repos/server-10-11/storage/innobase/buf/buf0flu.cc:1857:18: error: no matching function for call to ‘srw_lock_debug::wr_lock()’
 1857 |     latch.wr_lock();
      |     ~~~~~~~~~~~~~^~
/repos/server-10-11/storage/innobase/buf/buf0flu.cc:1857:18: note: there is 1 candidate
In file included from /repos/server-10-11/storage/innobase/include/log0log.h:33,
                 from /repos/server-10-11/storage/innobase/include/buf0flu.h:30,
                 from /repos/server-10-11/storage/innobase/buf/buf0flu.cc:33:
/repos/server-10-11/storage/innobase/include/srw_lock.h:607:8: note: candidate 1: ‘void srw_lock_debug::wr_lock(const char*, unsigned int)’
  607 |   void wr_lock(SRW_LOCK_ARGS(const char *file, unsigned line)) noexcept;
      |        ^~~~~~~
/repos/server-10-11/storage/innobase/include/srw_lock.h:607:8: note: candidate expects 2 arguments, 0 provided

Maybe the PFS instrumentation should be removed from debug lock as well somehow?

[dr-m]

This change is fixing the following combination:

cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DWITH_INNODB_EXTRA_DEBUG=ON …

In our internal testing, we use the rr record friendly option PLUGIN_PERFSCHEMA=NO. Yes, I noticed that the WITH_INNODB_EXTRA_DEBUG build would fail if that option is omitted.

Given that the excessive amount of conditional branches that PLUGIN_PERFSCHEMA is introducing (MDEV-33181) can hurt rr record performance by several orders of magnitude (I have observed over 1000× slowdown in the past), I didn’t want to spend more time on this.

[iMineLink]

Maybe we can just abandon the LOG_LATCH_DEBUG effort in log_t and comment that it may be reintroduced by providing adequate non-PFS instrumented debug support?