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.

The tracepoints are added via lightweight inline helpers in the
wrappers. When tracing is disabled, the fast path remains
unchanged.

The compaction changes required abstracting compact_lock_irqsave() away from
raw spinlock_t. I chose a small tagged struct to handle both zone and LRU
locks uniformly. If there is a preferred alternative (e.g. splitting helpers
or using a different abstraction), I would appreciate feedback.

Dmitry Ilvokhin (4):
  mm: introduce zone lock wrappers
  mm: convert zone lock users to wrappers
  mm: convert compaction to zone lock wrappers
  mm: add tracepoints for zone lock

 MAINTAINERS                      |   3 +
 include/linux/zone_lock.h        | 100 ++++++++++++++++++++++++++++
 include/trace/events/zone_lock.h |  64 ++++++++++++++++++
 mm/Makefile                      |   2 +-
 mm/compaction.c                  | 108 +++++++++++++++++++++++++------
 mm/memory_hotplug.c              |   9 +--
 mm/mm_init.c                     |   3 +-
 mm/page_alloc.c                  |  73 ++++++++++-----------
 mm/page_isolation.c              |  19 +++---
 mm/page_reporting.c              |  13 ++--
 mm/show_mem.c                    |   5 +-
 mm/vmscan.c                      |   5 +-
 mm/vmstat.c                      |   9 +--
 mm/zone_lock.c                   |  31 +++++++++
 14 files changed, 360 insertions(+), 84 deletions(-)
 create mode 100644 include/linux/zone_lock.h
 create mode 100644 include/trace/events/zone_lock.h
 create mode 100644 mm/zone_lock.c

-- 
2.47.3

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

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.

> 
> Thanks,
> Ben

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

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.

I don't think this suggestion will make anything better. This just seems like a
different taste. If I make a suggestion, I would request to squash (1) and (2)
i.e. patch containing wrappers and their use together but that is just my taste
and would be a nit. The series ordering is good as is.