Bug #100060 Switch to use optimal memory barriers for buf-fix-count and rseg-history-length
Submitted: 1 Jul 2020 9:07 Modified: 1 Jul 2020 12:40
Reporter: Krunal Bauskar Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S5 (Performance)
Version:8.0.20 OS:Any
Assigned to: CPU Architecture:ARM
Tags: buf-fix-count, memory barrier, trx-rseg-history-length

[1 Jul 2020 9:07] Krunal Bauskar
Description:
Switch to use optimal memory barriers for buf-fix-count and rseg-history-length

- Accessing a buffer page causes it to get pinned/fixed there-by incrementing
  buf-fix-count. On the completion, the page is unpinned/un-fixed there-by
  decrementing buf-fix-count.

- buf-fix-count is already atomic but it uses the default (sequential memory
  order) there-by making it non-optimal for relaxed memory model architecture
  viz. ARM and PowerPC.

- Patch proposes the use of relaxed memory order as the counter is just
  meant for increment and no synchronization is expected.

-----

- trx_sys->rseg_history_len is updated to reflect the undo log to purge.

- With a lot of small transactions, this variable is frequently updated by
  multiple threads. Given this aspect trx_sys->rseg_history_len is already
  atomic.

- Again, the flow uses the default (sequential memory order) there-by making
  it non-optimal for relaxed memory model atomic viz. ARM and PowerPC

- Patch proposes the use of relaxed memory order as the length is used to
  track counter and not meant for synchronization.

How to repeat:
Apply the patch that I will attach below.

Local testing revealed no regression on x86 but a clear gain on ARM (as expected). I will also attach the benchmark runs.

Note: Patch re-uses the structure introduced in bug#99556 by enhancing it further for performance (by adding cacheline padding) and more usability functions (fetch_add/sub/copy-constructor/etc....).
[1 Jul 2020 9:08] Krunal Bauskar
x86 benchmark

Attachment: x86.png (image/png, text), 122.11 KiB.

[1 Jul 2020 9:08] Krunal Bauskar
arm benchmark

Attachment: arm.png (image/png, text), 124.75 KiB.

[1 Jul 2020 12:40] MySQL Verification Team
Hello Mr. Bauskar,

Thank you very much for this performance improvement report.

I have studied your patch and concluded that you are quite correct.

Verified as reported.

Thanks again for tha patch.
[13 Aug 2020 16:27] Sunny Bains
I see drops on Intel at 64 threads, this makes it difficult to accept the performance claims (and patch).
[14 Aug 2020 12:09] MySQL Verification Team
Thank you, Sunny .....

This is a patch for the ARM architecture only.