On 2/11/2026 9:22 AM, Dmitry Ilvokhin wrote:
> Zone lock contention can significantly impact allocation and
> reclaim latency, as it is a central synchronization point in
> the page allocator and reclaim paths. Improved visibility into
> its behavior is therefore important for diagnosing performance
> issues in memory-intensive workloads.
>
> On some production workloads at Meta, we have observed noticeable
> zone lock contention. Deeper analysis of lock holders and waiters
> is currently difficult with existing instrumentation.
>
> While generic lock contention_begin/contention_end tracepoints
> cover the slow path, they do not provide sufficient visibility
> into lock hold times. In particular, the lack of a release-side
> event makes it difficult to identify long lock holders and
> correlate them with waiters. As a result, distinguishing between
> short bursts of contention and pathological long hold times
> requires additional instrumentation.
>
> This patch series adds dedicated tracepoint instrumentation to
> zone lock, following the existing mmap_lock tracing model.
>
> The goal is to enable detailed holder/waiter analysis and lock
> hold time measurements without affecting the fast path when
> tracing is disabled.
>
> The series is structured as follows:
>
> 1. Introduce zone lock wrappers.
> 2. Mechanically convert zone lock users to the wrappers.
> 3. Convert compaction to use the wrappers (requires minor
> restructuring of compact_lock_irqsave()).
> 4. Add zone lock tracepoints.
I think you can improve the flow of this series if reorder as follows:
1. Introduce zone lock wrappers
4. Add zone lock tracepoints
2. Mechanically convert zone lock users to the wrappers
3. Convert compaction to use the wrappers...
and possibly squash 1 & 4 (though that might be too big of a patch). It's
better to introduce the
wrappers and their tracepoints together before the reviewer (i.e. me) forgets
what was added in
patch 1 by the time they get to patch 4.
Thanks,
Ben
