On 2/23/2026 10:46 AM, Dmitry Ilvokhin wrote:
> [You don't often get email from [email protected]. 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
