Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-32065

Always check whether lock is free at first to optimize InnoDB mutexes

    XMLWordPrintable

Details

    Description

      `try_lock()` in InnoDB codes is an atomic operation. For example, it's compiled to "lock cmpxchg" in x86. It will force cacheline to be exclusive state and suffer significant performance degradation in heavy contended scenarios when many CPUs `try_lock()`.

      I collected a perf report and it's assembly codes in my benchmark. Attach them in files.

      Look at the TTASEventMutex implementation, for instance. We mark the codes, always check whether lock is free at first, then `try_lock()`.

      old:		while (!try_lock()) {
      new:		while (!(state() == MUTEX_STATE_UNLOCKED && try_lock())) {
      

      Based on real real-world workload test on a 224 CPUs x86 server, this change
      brings back 60%+ TPS/perf for MariaDB 10.3.

      Attachments

        Issue Links

          Activity

            People

              marko Marko Mäkelä
              yuhanyang yuhanyang
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.