MDEV-40210 Redundant CAS in async_flush_lsn::try_clear_if_at_most()#5300
MDEV-40210 Redundant CAS in async_flush_lsn::try_clear_if_at_most()#5300iMineLink wants to merge 1 commit into
Conversation
|
|
There was a problem hiding this comment.
Code Review
This pull request introduces an optimization in storage/innobase/buf/buf0flu.cc within the async_flush_lsn::try_clear_if_at_most function. It adds a check to return early if the snapshot is already zero, thereby avoiding a redundant atomic compare-and-swap (CAS) operation. There are no review comments, and we have no feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
There was a problem hiding this comment.
Pull request overview
This PR optimizes InnoDB’s page-cleaner hot path by avoiding a redundant atomic read-modify-write when the async flush LSN is already in the cleared state (0), preserving the same concurrency semantics while reducing cache-line contention.
Changes:
- Add an early return in
async_flush_lsn::try_clear_if_at_most()when the snapshotted LSN is0to skip a no-op CAS. - Reduce unnecessary exclusive access to the
m_lsncache line during steady-state page-cleaner passes.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
MDEV-39600 added try_clear_if_at_most() to clear buf_flush_async_lsn with an atomic CAS that preserves a concurrent bump(). If the snapshot is already 0, compare_exchange_strong(0, 0) is a no-op, so return early on a zero snapshot and avoid the atomic read-modify-write. The page cleaner calls this on every pass, so in the common steady state (no async flush queued) it drops needless exclusive access to the m_lsn cache line. A zero value is already the cleared state and a concurrent bump() is preserved either way, so the result is identical.
MDEV-39600 added try_clear_if_at_most() to clear buf_flush_async_lsn with an atomic CAS that preserves a concurrent bump(). If the snapshot is already 0, compare_exchange_strong(0, 0) is a no-op, so return early on a zero snapshot and avoid the atomic read-modify-write. The page cleaner calls this on every pass, so in the common steady state (no async flush queued) it drops needless exclusive access to the m_lsn cache line. A zero value is already the cleared state and a concurrent bump() is preserved either way, so the result is identical.