Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.6
Description
The synchronization primitives implemented in operating system libraries such as GNU libc may support lock elision via transactional memory when supported by the underlying hardware. The native primitives in InnoDB are currently missing that.
Lock elision could avoid unnecessary memory cache pollution in case a mutex is not contended. For example, when reading or sometimes even writing buf_pool.page_hash or lock_sys.rec_hash, we could avoid modifying cache lines only for the purpose of acquiring and releasing latches.
Attachments
Issue Links
- causes
-
MDEV-27936 hardware lock elision on ppc64{,le} failing to compile
- Closed
-
MDEV-30986 Slow full index scan in 10.6 vs 10.5 for the (slow) I/O-bound case
- Closed
- is blocked by
-
MDEV-26826 Duplicated computations of buf_pool.page_hash addresses
- Closed
-
MDEV-26828 Spinning on buf_pool.page_hash is wasting CPU cycles
- Closed
- relates to
-
MDEV-28137 Some memory transactions are unnecessarily complex
- Closed
-
MDEV-27222 FreeBSD 13.0-p4 build error mariadb-10.6.5
- Closed