[MDEV-26826] Duplicated computations of buf_pool.page_hash addresses Created: 2021-10-14  Updated: 2021-11-09  Resolved: 2021-10-22

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.5, 10.6, 10.7
Fix Version/s: 10.6.5, 10.7.1

Type: Bug Priority: Major
Reporter: Marko Mäkelä Assignee: Marko Mäkelä
Resolution: Fixed Votes: 0
Labels: performance

Attachments: PDF File sysbench.pdf    
Issue Links:
Blocks
blocks MDEV-26769 InnoDB internal latches do not suppor... Closed
is blocked by MDEV-26033 Race condition between buf_pool.page_... Closed
Relates
relates to MDEV-22871 Contention on the buf_pool.page_hash Closed

 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.

 Comments   
Comment by Axel Schwenke [ 2021-10-15 ]

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

Comment by Marko Mäkelä [ 2021-10-15 ]

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.

Comment by Marko Mäkelä [ 2021-10-15 ]

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.

Comment by Krunal Bauskar [ 2021-10-21 ]

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.

Comment by Marko Mäkelä [ 2021-10-21 ]

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

Generated at Thu Feb 08 09:48:15 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.