Re: [PATCH 0/4] mm: zone lock tracepoint instrumentation

["Cheatham, Benjamin" <benjamin.cheatham@amd.com>]

On 2/23/2026 10:46 AM, Dmitry Ilvokhin wrote:
> [You don't often get email from d@ilvokhin.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> On Fri, Feb 20, 2026 at 01:09:59PM -0600, Cheatham, Benjamin wrote:
>> 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.
> 
> Hi Ben,
> 
> Thanks for the suggestion.
> 
> I structured the series intentionally to keep all behavior-preserving
> refactoring separate from the actual instrumentation change.
> 
> In particular, I had to split the conversion into two patches to
> separate the purely mechanical changes from the compaction
> restructuring. With the current order, tracepoints addition remains a
> single, atomic functional change on top of a fully converted tree. This
> keeps the instrumentation isolated from the refactoring and with an
> intention to make bisection and review of the behavioral change easier.
> 
> Reordering as suggested would mix instrumentation with intermediate
> refactoring states, which I'd prefer to avoid.
> 
> I hope this reasoning makes sense, but I'm happy to discuss if there are
> strong objections.

No that's fine, I figured as much. I just wasn't sure that was more important
to you than what (I thought) was a better reading order for the series.

Thanks,
Ben

> 
>>
>> Thanks,
>> Ben