-
Type:
Task
-
Resolution: Works as Designed
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Not Applicable
-
None
-
Storage Engines, Storage Engines - Transactions
-
0.179
-
None
-
None
Summary
Investigate whether the eviction subsystem can tolerate a page appearing in more than one eviction queue, so we can relax the single-membership requirement and avoid taking evict_queue_lock on the LRU walk push path.
Background
WT-17412 fixed a race by acquiring evict_queue_lock around the point where the LRU walk sets WT_PAGE_EVICT_LRU and pushes a candidate. The lock is required today because eviction bookkeeping assumes a page is in at most one queue:* The queued state is a single flag bit on the page (WT_PAGE_EVICT_LRU), not a count.
- Entries are cleared with clear-on-pop, which clears that one bit and asserts it was set.
- The queue drain trusts the entry and dereferences ref->page.
Given that model, double queuing leads to a dangling entry: once one entry evicts and frees the page, any other entry pointing at the same page follows freed memory. The urgent path deliberately clears a page from the regular queue before inserting it into the urgent queue to preserve single membership, and the discard-time assertion in __wt_page_out (present since 2012, no recorded incident) guards the same invariant.
Idea to investigate
Move the queued state off the page and onto the ref, and make the drain validate ref state instead of dereferencing a possibly-freed page. If the drain skips entries whose ref is no longer in the in-memory state, then:
- A stale or duplicate queue entry becomes harmless rather than a use-after-free.
- The single-membership requirement (and therefore the evict_queue_lock acquisition on the walk push path) may no longer be needed.
- The discard-time assertion could be removed, since the page would no longer carry queue state. Note the invariant shifts to ref teardown (splits, parent-page discard), which would need equivalent handling.
Goals
- Determine whether double queuing can be made safe with a validate-on-drain, ref-based design.
- Assess whether the walk push path can drop evict_queue_lock, and the performance impact.
- Scope the change to ref teardown paths (splits, parent discard) that would inherit the invariant.
Related
- WT-17412 (the lock fix this would potentially relax)
- related to
-
WT-17412 Fix race: hold evict_queue_lock around WT_PAGE_EVICT_LRU CAS in push candidate
-
- Closed
-