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

Duplicated computations of buf_pool.page_hash addresses

Details

    Description

      MDEV-22871 could have made the parameter guess that is being passed in a few calls to buf_page_get_gen() considerably less useful. The reason is that we will have to perform a hash table lookup anyway in order to compute the address of page_hash_latch, which will protect our attempt to validate guess.

      Maintaining and passing the guess could cause some overhead. However, an attempt to remove that parameter caused prominent performance regressions, possibly due to trx_undo_t::guess_block. So, we’d better keep that parameter.

      What we can and should do instead is to refactor the buf_pool.page_hash code so that the address in buf_pool.page_hash.array will be computed while not holding any mutexes. This became possible after the fix of MDEV-26033.

      Attachments

        Issue Links

          blocks

          Bug - A problem which impairs or prevents the functions of the product. MDEV-26769 InnoDB internal latches do not support hardware lock elision

          • Major - Major loss of function.
          • Closed
          is blocked by

          Bug - A problem which impairs or prevents the functions of the product. MDEV-26033 Race condition between buf_pool.page_hash and buffer pool resizing

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed
          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-22871 Contention on the buf_pool.page_hash

          • Blocker - Blocks development and/or testing work, production could not run.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            axel Axel Schwenke added a comment - - edited

            Results in attached sysbench.pdf show some progress for read-only workload, but regressions for mixed workload.

            axel Axel Schwenke added a comment - - edited Results in attached sysbench.pdf show some progress for read-only workload, but regressions for mixed workload.
            marko Marko Mäkelä added a comment -

            Thank you. I should check if buf_page_get_low() is unnecessarily calculating the hash table address twice. The address of the latch could be obtained by simply masking some bits of the address of the hash bucket. We might currently calculate the address twice, or once if the guess parameter is valid.

            marko Marko Mäkelä added a comment - Thank you. I should check if buf_page_get_low() is unnecessarily calculating the hash table address twice. The address of the latch could be obtained by simply masking some bits of the address of the hash bucket. We might currently calculate the address twice, or once if the guess parameter is valid.
            marko Marko Mäkelä added a comment - - edited

            It turns out that in MDEV-26033 we missed some optimization opportunity. Now that the location and size of buf_pool.page_hash will remain unchanged, we can calculate the hash table cell and latch address while not holding any mutex. Furthermore, we can first calculate the address of the cell, and then calculate the address of the latch by a simple bitmask operation. This should relieve buf_pool.mutex some more.

            marko Marko Mäkelä added a comment - - edited It turns out that in MDEV-26033 we missed some optimization opportunity . Now that the location and size of buf_pool.page_hash will remain unchanged, we can calculate the hash table cell and latch address while not holding any mutex. Furthermore, we can first calculate the address of the cell, and then calculate the address of the latch by a simple bitmask operation. This should relieve buf_pool.mutex some more.
            krunalbauskar Krunal Bauskar added a comment -

            I have completed benchmarking of this said branch
            1. x86 shows performance gain in range of 1-6% but there is bit of noise with update-non-index workload. (will check this out)
            2. ARM shows regression for uniform workload (up to -3%). For zipfian it shows 2-10% performance gain.

            krunalbauskar Krunal Bauskar added a comment - I have completed benchmarking of this said branch 1. x86 shows performance gain in range of 1-6% but there is bit of noise with update-non-index workload. (will check this out) 2. ARM shows regression for uniform workload (up to -3%). For zipfian it shows 2-10% performance gain.
            marko Marko Mäkelä added a comment -

            krunalbauskar, thank you. The commit that you probably tested also included MDEV-26828 as the parent commit.

            marko Marko Mäkelä added a comment - krunalbauskar , thank you. The commit that you probably tested also included MDEV-26828 as the parent commit.

            People

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

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

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