Details
-
Task
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
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
- relates to
-
MDEV-21452 Use condition variables and normal mutexes instead of InnoDB os_event and mutex
- Closed
-
MDEV-24142 rw_lock_t has unnecessarily complex wait logic
- Closed
-
MDEV-24167 InnoDB unnecessarily uses complex rw-lock implementation
- Closed
-
MDEV-26467 Unnecessary compare-and-swap loop in futex-based synchronization
- Closed