buf_pool.mutex contention under I/O-limited OLTP workload

Goal

Reduce buf_pool.mutex contention observed under heavy I/O-limited OLTP workloads (HammerDB TPROC-C UAW), where the bottleneck is page-flushing — both long stalls at checkpoint and free-list starvation when the buffer pool is under pressure.

Current plan (revised 2026-06-16)

After PERF-475 results came in, the priority order for this Epic has changed. Flushing is the dominant issue for the RW workload tested here; page_hash contention work moves to the front.

Under investigation (no MDEV yet)

Alessandro has pushed several small candidate commits under the PERF-475 umbrella for testing. Rahul Raj is running those through a perf round. Any that prove promising will be opened as new MDEVs and linked here as Epic children.

Background

The contention surfaces in HammerDB TPROC-C UAW runs at 64G and 128G buffer pool sizes (see attachments). Flame graphs and off-CPU profiles point at the flushing path rather than the page-hash lookup path for this specific workload — the original assumption (that page_hash sharding alone would carry the win) does not hold; flushing-side wins matter more.

Definition of done for this Epic

• MDEV-39084 lands and demonstrates a measurable reduction of buf_pool.mutex contention on the HammerDB TPROC-C UAW reference workload.
• Any PERF-475-derived MDEVs that get opened are landed or formally deferred with rationale.
• MDEV-33966 either lands its patch under the read-heavy scope or is decoupled into its own tracking Epic if it grows out of scope here.
• No remaining "background research" line items — anything we learn from this Epic that isn't fixed gets either a new MDEV or a documented "won't fix" rationale.

Sprint allocation guidance

This Epic remains a research / coordination container — it does not consume sprint capacity itself (5d estimate kept). All actual development effort is tracked under the child MDEVs above.