mm: zone lock tracepoint instrumentation

Add thin wrappers around zone lock acquire/release operations. This prepares the code for future tracepoint instrumentation without modifying individual call sites.

Centralizing zone lock operations behind wrappers allows future instrumentation or debugging hooks to be added without touching all users.

No functional change intended. The wrappers are introduced in preparation for subsequent patches and are not yet used.

Signed-off-by Dmitry Ilvokhin <[email protected]>

Acked-by Shakeel Butt <[email protected]>

---

Add thin wrappers around zone lock acquire/release operations. This prepares the code for future tracepoint instrumentation without modifying individual call sites.

Centralizing zone lock operations behind wrappers allows future instrumentation or debugging hooks to be added without touching all users.

No functional change intended. The wrappers are introduced in preparation for subsequent patches and are not yet used.

Signed-off-by Dmitry Ilvokhin <[email protected]>

Acked-by Shakeel Butt <[email protected]>

---
 MAINTAINERS                 |  1 +
 include/linux/mmzone_lock.h | 38 +++++++++++++++++++++++++++++++++++++
 2 files changed, 39 insertions(+)
 create mode 100644 include/linux/mmzone_lock.h

Add thin wrappers around zone lock acquire/release operations. This prepares the code for future tracepoint instrumentation without modifying individual call sites.

Centralizing zone lock operations behind wrappers allows future instrumentation or debugging hooks to be added without touching all users.

No functional change intended. The wrappers are introduced in preparation for subsequent patches and are not yet used.

Signed-off-by Dmitry Ilvokhin <[email protected]>

Acked-by Shakeel Butt <[email protected]>

Add thin wrappers around zone lock acquire/release operations. This prepares the code for future tracepoint instrumentation without modifying individual call sites.

Centralizing zone lock operations behind wrappers allows future instrumentation or debugging hooks to be added without touching all users.

No functional change intended. The wrappers are introduced in preparation for subsequent patches and are not yet used.

Signed-off-by Dmitry Ilvokhin <[email protected]>

Acked-by Shakeel Butt <[email protected]>

---
 MAINTAINERS                 |  1 +
 include/linux/mmzone_lock.h | 38 +++++++++++++++++++++++++++++++++++++
 2 files changed, 39 insertions(+)
 create mode 100644 include/linux/mmzone_lock.h

MAINTAINERS +1 -0

index 55af015174a5..947298ecb111 100644
@@ -16672,6 +16672,7 @@ F:	include/linux/memory.h
 F:	include/linux/mm.h
 F:	include/linux/mm_*.h
 F:	include/linux/mmzone.h
+F:	include/linux/mmzone_lock.h
 F:	include/linux/mmdebug.h
 F:	include/linux/mmu_notifier.h
 F:	include/linux/pagewalk.h

include/linux/mmzone_lock.h new file +38 -0

new file mode 100644
index 000000000000..a1cfba8408d6
@@ -0,0 +1,38 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_MMZONE_LOCK_H
+#define _LINUX_MMZONE_LOCK_H
+
+#include <linux/mmzone.h>
+#include <linux/spinlock.h>
+
+static inline void zone_lock_init(struct zone *zone)
+{
+	spin_lock_init(&zone->lock);
+}
+
+#define zone_lock_irqsave(zone, flags)				\
+do {								\
+	spin_lock_irqsave(&(zone)->lock, flags);		\
+} while (0)
+
+#define zone_trylock_irqsave(zone, flags)			\
+({								\
+	spin_trylock_irqsave(&(zone)->lock, flags);		\
+})
+
+static inline void zone_unlock_irqrestore(struct zone *zone, unsigned long flags)
+{
+	spin_unlock_irqrestore(&zone->lock, flags);
+}
+
+static inline void zone_lock_irq(struct zone *zone)
+{
+	spin_lock_irq(&zone->lock);
+}
+
+static inline void zone_unlock_irq(struct zone *zone)
+{
+	spin_unlock_irq(&zone->lock);
+}
+
+#endif /* _LINUX_MMZONE_LOCK_H */

Replace direct zone lock acquire/release operations with the newly introduced wrappers.

The changes are purely mechanical substitutions. No functional change intended. Locking semantics and ordering remain unchanged.

The compaction path is left unchanged for now and will be handled separately in the following patch due to additional non-trivial modifications.

Signed-off-by Dmitry Ilvokhin <[email protected]>

Acked-by Shakeel Butt <[email protected]>

Reviewed-by SeongJae Park <[email protected]>

---

Quoted 14 lines · Dmitry Ilvokhin

Replace direct zone lock acquire/release operations with the newly introduced wrappers.

The changes are purely mechanical substitutions. No functional change intended. Locking semantics and ordering remain unchanged.

The compaction path is left unchanged for now and will be handled separately in the following patch due to additional non-trivial modifications.

Signed-off-by Dmitry Ilvokhin <[email protected]>

Acked-by Shakeel Butt <[email protected]>

Reviewed-by SeongJae Park <[email protected]>

---

[...]

mm/compaction.c static bool compact_lock_irqsave(spinlock_t *lock, unsigned long *flags, · line 538

Quoted 12 lines

#ifdef CONFIG_COMPACTION

mm/compaction.c +5 -2

@@ -530,11 +531,14 @@ static bool compact_lock_irqsave(spinlock_t *lock, unsigned long *flags,
  * Returns true if compaction should abort due to fatal signal pending.
  * Returns false when compaction can continue.
  */
-static bool compact_unlock_should_abort(spinlock_t *lock,
-		unsigned long flags, bool *locked, struct compact_control *cc)
+
+static bool compact_unlock_should_abort(struct zone *zone,
+					unsigned long flags,
+					bool *locked,
+					struct compact_control *cc)

We tend to use two-tabs on second parameter line; like the existing code did.

Besides that

Acked-by David Hildenbrand (Arm) <[email protected]>

Signature · 3 lines

Cheers,

David

Replace direct zone lock acquire/release operations with the newly introduced wrappers.

The changes are purely mechanical substitutions. No functional change intended. Locking semantics and ordering remain unchanged.

The compaction path is left unchanged for now and will be handled separately in the following patch due to additional non-trivial modifications.

Signed-off-by Dmitry Ilvokhin <[email protected]>

Acked-by Shakeel Butt <[email protected]>

Reviewed-by SeongJae Park <[email protected]>

---
 kernel/power/snapshot.c |  5 +--
 mm/compaction.c         | 25 +++++++-------
 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/shuffle.c            |  9 ++---
 mm/vmscan.c             |  5 +--
 mm/vmstat.c             |  9 ++---
 11 files changed, 94 insertions(+), 81 deletions(-)

Replace direct zone lock acquire/release operations with the newly introduced wrappers.

The changes are purely mechanical substitutions. No functional change intended. Locking semantics and ordering remain unchanged.

The compaction path is left unchanged for now and will be handled separately in the following patch due to additional non-trivial modifications.

Signed-off-by Dmitry Ilvokhin <[email protected]>

Acked-by Shakeel Butt <[email protected]>

Reviewed-by SeongJae Park <[email protected]>

Compaction uses compact_lock_irqsave(), which currently operates on a raw spinlock_t pointer so it can be used for both zone->lock and lruvec->lru_lock. Since zone lock operations are now wrapped, compact_lock_irqsave() can no longer directly operate on a spinlock_t when the lock belongs to a zone.

Split the helper into compact_zone_lock_irqsave() and compact_lruvec_lock_irqsave(), duplicating the small amount of shared logic. As there are only two call sites and both statically know the lock type, this avoids introducing additional abstraction or runtime dispatch in the compaction path.

No functional change intended.

Signed-off-by Dmitry Ilvokhin <[email protected]>

Acked-by Shakeel Butt <[email protected]>

---
 mm/compaction.c | 33 ++++++++++++++++++++++++---------
 1 file changed, 24 insertions(+), 9 deletions(-)

mm/compaction.c +0 -0

index fa0e332a8a92..c68fcc416fc7 100644

Compaction uses compact_lock_irqsave(), which currently operates on a raw spinlock_t pointer so it can be used for both zone->lock and lruvec->lru_lock. Since zone lock operations are now wrapped, compact_lock_irqsave() can no longer directly operate on a spinlock_t when the lock belongs to a zone.

Split the helper into compact_zone_lock_irqsave() and compact_lruvec_lock_irqsave(), duplicating the small amount of shared logic. As there are only two call sites and both statically know the lock type, this avoids introducing additional abstraction or runtime dispatch in the compaction path.

No functional change intended.

Signed-off-by Dmitry Ilvokhin <[email protected]>

Acked-by Shakeel Butt <[email protected]>

---
 mm/compaction.c | 33 ++++++++++++++++++++++++---------
 1 file changed, 24 insertions(+), 9 deletions(-)

Compaction uses compact_lock_irqsave(), which currently operates on a raw spinlock_t pointer so it can be used for both zone->lock and lruvec->lru_lock. Since zone lock operations are now wrapped, compact_lock_irqsave() can no longer directly operate on a spinlock_t when the lock belongs to a zone.

Split the helper into compact_zone_lock_irqsave() and compact_lruvec_lock_irqsave(), duplicating the small amount of shared logic. As there are only two call sites and both statically know the lock type, this avoids introducing additional abstraction or runtime dispatch in the compaction path.

No functional change intended.

Signed-off-by Dmitry Ilvokhin <[email protected]>

Acked-by Shakeel Butt <[email protected]>

Compaction uses compact_lock_irqsave(), which currently operates on a raw spinlock_t pointer so it can be used for both zone->lock and lruvec->lru_lock. Since zone lock operations are now wrapped, compact_lock_irqsave() can no longer directly operate on a spinlock_t when the lock belongs to a zone.

Split the helper into compact_zone_lock_irqsave() and compact_lruvec_lock_irqsave(), duplicating the small amount of shared logic. As there are only two call sites and both statically know the lock type, this avoids introducing additional abstraction or runtime dispatch in the compaction path.

No functional change intended.

Signed-off-by Dmitry Ilvokhin <[email protected]>

Acked-by Shakeel Butt <[email protected]>

This intentionally breaks direct users of zone->lock at compile time so all call sites are converted to the zone lock wrappers. Without the rename, present and future out-of-tree code could continue using spin_lock(&zone->lock) and bypass the wrappers and tracing infrastructure.

No functional change intended.

Suggested-by Andrew Morton <[email protected]>

Signed-off-by Dmitry Ilvokhin <[email protected]>

Acked-by Shakeel Butt <[email protected]>

Acked-by SeongJae Park <[email protected]>

---

This intentionally breaks direct users of zone->lock at compile time so all call sites are converted to the zone lock wrappers. Without the rename, present and future out-of-tree code could continue using spin_lock(&zone->lock) and bypass the wrappers and tracing infrastructure.

No functional change intended.

Suggested-by Andrew Morton <[email protected]>

Signed-off-by Dmitry Ilvokhin <[email protected]>

Acked-by Shakeel Butt <[email protected]>

Acked-by SeongJae Park <[email protected]>

---
 include/linux/mmzone.h      |  7 +++++--
 include/linux/mmzone_lock.h | 12 ++++++------
 mm/compaction.c             |  4 ++--
 mm/internal.h               |  2 +-
 mm/page_alloc.c             | 16 ++++++++--------
 mm/page_isolation.c         |  4 ++--
 mm/page_owner.c             |  2 +-
 7 files changed, 25 insertions(+), 22 deletions(-)

This intentionally breaks direct users of zone->lock at compile time so all call sites are converted to the zone lock wrappers. Without the rename, present and future out-of-tree code could continue using spin_lock(&zone->lock) and bypass the wrappers and tracing infrastructure.

No functional change intended.

Suggested-by Andrew Morton <[email protected]>

Signed-off-by Dmitry Ilvokhin <[email protected]>

Acked-by Shakeel Butt <[email protected]>

Acked-by SeongJae Park <[email protected]>

Quoted 8 lines · Dmitry Ilvokhin

This intentionally breaks direct users of zone->lock at compile time so all call sites are converted to the zone lock wrappers. Without the rename, present and future out-of-tree code could continue using spin_lock(&zone->lock) and bypass the wrappers and tracing infrastructure.

No functional change intended.

Quoted 4 lines

Suggested-by Andrew Morton <[email protected]>

Signed-off-by Dmitry Ilvokhin <[email protected]>

Acked-by Shakeel Butt <[email protected]>

Acked-by SeongJae Park <[email protected]>

I see some more instances of 'zone->lock' in comments in include/linux/mmzone.h and under Documentation/ but otherwise LGTM.

Quoted 14 lines · On Mon, 2 Mar 2026 15:10:03 +0100 "Vlastimil Babka (SUSE)" <[email protected]>…

Quoted 12 lines · Dmitry Ilvokhin

This intentionally breaks direct users of zone->lock at compile time so all call sites are converted to the zone lock wrappers. Without the rename, present and future out-of-tree code could continue using spin_lock(&zone->lock) and bypass the wrappers and tracing infrastructure.

No functional change intended.

Suggested-by Andrew Morton <[email protected]>

Signed-off-by Dmitry Ilvokhin <[email protected]>

Acked-by Shakeel Butt <[email protected]>

Acked-by SeongJae Park <[email protected]>

Quoted 3 lines

I see some more instances of 'zone->lock' in comments in include/linux/mmzone.h and under Documentation/ but otherwise LGTM.

I fixed (most of) that in the previous version but my fix was lost.

Quoted 16 lines · Andrew Morton

Quoted 14 lines · On Mon, 2 Mar 2026 15:10:03 +0100 "Vlastimil Babka (SUSE)" <[email protected]>…

Quoted 12 lines · Dmitry Ilvokhin

This intentionally breaks direct users of zone->lock at compile time so all call sites are converted to the zone lock wrappers. Without the rename, present and future out-of-tree code could continue using spin_lock(&zone->lock) and bypass the wrappers and tracing infrastructure.

No functional change intended.

Suggested-by Andrew Morton <[email protected]>

Signed-off-by Dmitry Ilvokhin <[email protected]>

Acked-by Shakeel Butt <[email protected]>

Acked-by SeongJae Park <[email protected]>

Quoted 5 lines

Quoted 3 lines

I see some more instances of 'zone->lock' in comments in include/linux/mmzone.h and under Documentation/ but otherwise LGTM.

I fixed (most of) that in the previous version but my fix was lost.

Thanks for the fixups, Andrew.

I still see a few 'zone->lock' references in Documentation remain on mm-new. This patch cleans them up, as noted by Vlastimil.

I'm happy to adjust this patch if anything else needs attention.

From 9142d5a8b60038fa424a6033253960682e5a51f4 Mon Sep 17 00:00:00 2001
From: Dmitry Ilvokhin <[email protected]>
Date: Tue, 3 Mar 2026 06:13:13 -0800
Subject: [PATCH] mm: fix remaining zone->lock references

Signed-off-by Dmitry Ilvokhin <[email protected]>

---
 Documentation/mm/physical_memory.rst | 4 ++--
 Documentation/trace/events-kmem.rst  | 8 ++++----
 2 files changed, 6 insertions(+), 6 deletions(-)

Documentation/mm/physical_memory.rst +0 -0

index b76183545e5b..e344f93515b6 100644

Quoted 46 lines · On Tue, 3 Mar 2026 14:25:55 +0000 Dmitry Ilvokhin <[email protected]> wrote:

Quoted 16 lines · Andrew Morton

Quoted 14 lines · On Mon, 2 Mar 2026 15:10:03 +0100 "Vlastimil Babka (SUSE)" <[email protected]>…

Quoted 12 lines · Dmitry Ilvokhin

This intentionally breaks direct users of zone->lock at compile time so all call sites are converted to the zone lock wrappers. Without the rename, present and future out-of-tree code could continue using spin_lock(&zone->lock) and bypass the wrappers and tracing infrastructure.

No functional change intended.

Suggested-by Andrew Morton <[email protected]>

Signed-off-by Dmitry Ilvokhin <[email protected]>

Acked-by Shakeel Butt <[email protected]>

Acked-by SeongJae Park <[email protected]>

Quoted 5 lines

Quoted 3 lines

I see some more instances of 'zone->lock' in comments in include/linux/mmzone.h and under Documentation/ but otherwise LGTM.

I fixed (most of) that in the previous version but my fix was lost.

Thanks for the fixups, Andrew.

I still see a few 'zone->lock' references in Documentation remain on mm-new. This patch cleans them up, as noted by Vlastimil.

I'm happy to adjust this patch if anything else needs attention.

From 9142d5a8b60038fa424a6033253960682e5a51f4 Mon Sep 17 00:00:00 2001
From: Dmitry Ilvokhin <[email protected]>
Date: Tue, 3 Mar 2026 06:13:13 -0800
Subject: [PATCH] mm: fix remaining zone->lock references

Signed-off-by Dmitry Ilvokhin <[email protected]>

---
 Documentation/mm/physical_memory.rst | 4 ++--
 Documentation/trace/events-kmem.rst  | 8 ++++----
 2 files changed, 6 insertions(+), 6 deletions(-)

Documentation/mm/physical_memory.rst +0 -0

index b76183545e5b..e344f93515b6 100644

Documentation/mm/physical_memory.rst General · line 503

Quoted 5 lines

Documentation/mm/physical_memory.rst +1 -1

@@ -500,11 +500,11 @@ General
 ``nr_isolate_pageblock``
   Number of isolated pageblocks. It is used to solve incorrect freepage counting
   problem due to racy retrieving migratetype of pageblock. Protected by
-  ``zone->lock``. Defined only when ``CONFIG_MEMORY_ISOLATION`` is enabled.
+  ``zone_lock``. Defined only when ``CONFIG_MEMORY_ISOLATION`` is enabled.

Dmitry's original patch [1] was doing 's/zone->lock/zone->_lock/', which aligns to my expectation. But this patch is doing 's/zone->lock/zone_lock/'. Same for the rest of this patch.

I was initially thinking this is just a mistake, but I also found Andrew is doing same change [2], so I'm bit confused. Is this an intentional change?

[1] https://lore.kernel.org/d61500c5784c64e971f4d328c57639303c475f81.1772206930.git.d@ilvokhin.com
[2] https://lore.kernel.org/[email protected]

Thanks,
SJ

[...]

Quoted 58 lines · SeongJae Park

Quoted 46 lines · On Tue, 3 Mar 2026 14:25:55 +0000 Dmitry Ilvokhin <[email protected]> wrote:

Quoted 16 lines · Andrew Morton

Quoted 14 lines · On Mon, 2 Mar 2026 15:10:03 +0100 "Vlastimil Babka (SUSE)" <[email protected]>…

Quoted 12 lines · Dmitry Ilvokhin

This intentionally breaks direct users of zone->lock at compile time so all call sites are converted to the zone lock wrappers. Without the rename, present and future out-of-tree code could continue using spin_lock(&zone->lock) and bypass the wrappers and tracing infrastructure.

No functional change intended.

Suggested-by Andrew Morton <[email protected]>

Signed-off-by Dmitry Ilvokhin <[email protected]>

Acked-by Shakeel Butt <[email protected]>

Acked-by SeongJae Park <[email protected]>

Quoted 5 lines

Quoted 3 lines

I see some more instances of 'zone->lock' in comments in include/linux/mmzone.h and under Documentation/ but otherwise LGTM.

I fixed (most of) that in the previous version but my fix was lost.

Thanks for the fixups, Andrew.

I still see a few 'zone->lock' references in Documentation remain on mm-new. This patch cleans them up, as noted by Vlastimil.

I'm happy to adjust this patch if anything else needs attention.

From 9142d5a8b60038fa424a6033253960682e5a51f4 Mon Sep 17 00:00:00 2001
From: Dmitry Ilvokhin <[email protected]>
Date: Tue, 3 Mar 2026 06:13:13 -0800
Subject: [PATCH] mm: fix remaining zone->lock references

Signed-off-by Dmitry Ilvokhin <[email protected]>

---
 Documentation/mm/physical_memory.rst | 4 ++--
 Documentation/trace/events-kmem.rst  | 8 ++++----
 2 files changed, 6 insertions(+), 6 deletions(-)

Documentation/mm/physical_memory.rst +0 -0

index b76183545e5b..e344f93515b6 100644

Documentation/mm/physical_memory.rst General · line 503

Quoted 5 lines

Documentation/mm/physical_memory.rst +1 -1

@@ -500,11 +500,11 @@ General
 ``nr_isolate_pageblock``
   Number of isolated pageblocks. It is used to solve incorrect freepage counting
   problem due to racy retrieving migratetype of pageblock. Protected by
-  ``zone->lock``. Defined only when ``CONFIG_MEMORY_ISOLATION`` is enabled.
+  ``zone_lock``. Defined only when ``CONFIG_MEMORY_ISOLATION`` is enabled.

Dmitry's original patch [1] was doing 's/zone->lock/zone->_lock/', which aligns to my expectation. But this patch is doing 's/zone->lock/zone_lock/'. Same for the rest of this patch.

Quoted 6 lines

I was initially thinking this is just a mistake, but I also found Andrew is doing same change [2], so I'm bit confused. Is this an intentional change?

[1] https://lore.kernel.org/d61500c5784c64e971f4d328c57639303c475f81.1772206930.git.d@ilvokhin.com
[2] https://lore.kernel.org/[email protected]

Good catch, thanks for pointing this out, SJ.

Originally the mechanical rename was indeed zone->lock -> zone->_lock. However, in Documentation I intentionally switched references to zone_lock instead of zone->_lock. The reasoning is that _lock is now an internal implementation detail, and direct access is discouraged. The intended interface is via the zone_lock_*() / zone_unlock_*() wrappers, so referencing zone_lock in documentation felt more appropriate than mentioning the private struct field (zone->_lock).

That said, I agree this creates inconsistency with the mechanical rename, and I'm happy to adjust either way: either consistently refer to the wrapper API, or keep documentation aligned with zone->_lock.

I slightly prefer referring to the wrapper API, but don't have a strong preference as long as we're consistent.

Quoted 68 lines · On Wed, 4 Mar 2026 13:01:45 +0000 Dmitry Ilvokhin <[email protected]> wrote:

Quoted 58 lines · SeongJae Park

Quoted 46 lines · On Tue, 3 Mar 2026 14:25:55 +0000 Dmitry Ilvokhin <[email protected]> wrote:

Quoted 16 lines · Andrew Morton

Quoted 14 lines · On Mon, 2 Mar 2026 15:10:03 +0100 "Vlastimil Babka (SUSE)" <[email protected]>…

Quoted 12 lines · Dmitry Ilvokhin

This intentionally breaks direct users of zone->lock at compile time so all call sites are converted to the zone lock wrappers. Without the rename, present and future out-of-tree code could continue using spin_lock(&zone->lock) and bypass the wrappers and tracing infrastructure.

No functional change intended.

Suggested-by Andrew Morton <[email protected]>

Signed-off-by Dmitry Ilvokhin <[email protected]>

Acked-by Shakeel Butt <[email protected]>

Acked-by SeongJae Park <[email protected]>

Quoted 5 lines

Quoted 3 lines

I see some more instances of 'zone->lock' in comments in include/linux/mmzone.h and under Documentation/ but otherwise LGTM.

I fixed (most of) that in the previous version but my fix was lost.

Thanks for the fixups, Andrew.

I still see a few 'zone->lock' references in Documentation remain on mm-new. This patch cleans them up, as noted by Vlastimil.

I'm happy to adjust this patch if anything else needs attention.

From 9142d5a8b60038fa424a6033253960682e5a51f4 Mon Sep 17 00:00:00 2001
From: Dmitry Ilvokhin <[email protected]>
Date: Tue, 3 Mar 2026 06:13:13 -0800
Subject: [PATCH] mm: fix remaining zone->lock references

Signed-off-by Dmitry Ilvokhin <[email protected]>

---
 Documentation/mm/physical_memory.rst | 4 ++--
 Documentation/trace/events-kmem.rst  | 8 ++++----
 2 files changed, 6 insertions(+), 6 deletions(-)

Documentation/mm/physical_memory.rst +0 -0

index b76183545e5b..e344f93515b6 100644

Documentation/mm/physical_memory.rst General · line 503

Quoted 5 lines

Documentation/mm/physical_memory.rst +1 -1

@@ -500,11 +500,11 @@ General
 ``nr_isolate_pageblock``
   Number of isolated pageblocks. It is used to solve incorrect freepage counting
   problem due to racy retrieving migratetype of pageblock. Protected by
-  ``zone->lock``. Defined only when ``CONFIG_MEMORY_ISOLATION`` is enabled.
+  ``zone_lock``. Defined only when ``CONFIG_MEMORY_ISOLATION`` is enabled.

Dmitry's original patch [1] was doing 's/zone->lock/zone->_lock/', which aligns to my expectation. But this patch is doing 's/zone->lock/zone_lock/'. Same for the rest of this patch.

Quoted 6 lines

I was initially thinking this is just a mistake, but I also found Andrew is doing same change [2], so I'm bit confused. Is this an intentional change?

[1] https://lore.kernel.org/d61500c5784c64e971f4d328c57639303c475f81.1772206930.git.d@ilvokhin.com
[2] https://lore.kernel.org/[email protected]

Good catch, thanks for pointing this out, SJ.

Quoted 7 lines

Originally the mechanical rename was indeed zone->lock -> zone->_lock. However, in Documentation I intentionally switched references to zone_lock instead of zone->_lock. The reasoning is that _lock is now an internal implementation detail, and direct access is discouraged. The intended interface is via the zone_lock_*() / zone_unlock_*() wrappers, so referencing zone_lock in documentation felt more appropriate than mentioning the private struct field (zone->_lock).

Thank you for this nice and kind clarification, Dmitry! I agree mentioning zone_[un]lock_*() helpers instead of the hidden member (zone->_lock) can be better.

But, I'm concerned if people like me might not aware the intention under 'zone_lock'. If there is a well-known convention that allows people to know it is for 'zone_[un]lock_*()' helpers, making it more clear would be nice, in my humble opinion. If there is such a convention but I'm just missing it, please ignore. If I'm not, for eaxmaple,

"protected by ``zone->lock``" could be re-wrote to "protected by ``zone_[un]lock_*()`` locking helpers" or, "protected by zone lock helper functions (``zone_[un]lock_*()``)" ?

Quoted 8 lines

That said, I agree this creates inconsistency with the mechanical rename, and I'm happy to adjust either way: either consistently refer to the wrapper API, or keep documentation aligned with zone->_lock.

I slightly prefer referring to the wrapper API, but don't have a strong preference as long as we're consistent.

I also think both approaches are good. But for the wrapper approach, I think giving more contexts rather than just ``zone_lock`` to readers would be nice.

Quoted 68 lines · On Wed, 4 Mar 2026 13:01:45 +0000 Dmitry Ilvokhin <[email protected]> wrote:

Quoted 58 lines · SeongJae Park

Quoted 46 lines · On Tue, 3 Mar 2026 14:25:55 +0000 Dmitry Ilvokhin <[email protected]> wrote:

Quoted 16 lines · Andrew Morton

Quoted 14 lines · On Mon, 2 Mar 2026 15:10:03 +0100 "Vlastimil Babka (SUSE)" <[email protected]>…

Quoted 12 lines · Dmitry Ilvokhin

This intentionally breaks direct users of zone->lock at compile time so all call sites are converted to the zone lock wrappers. Without the rename, present and future out-of-tree code could continue using spin_lock(&zone->lock) and bypass the wrappers and tracing infrastructure.

No functional change intended.

Suggested-by Andrew Morton <[email protected]>

Signed-off-by Dmitry Ilvokhin <[email protected]>

Acked-by Shakeel Butt <[email protected]>

Acked-by SeongJae Park <[email protected]>

Quoted 5 lines

Quoted 3 lines

I see some more instances of 'zone->lock' in comments in include/linux/mmzone.h and under Documentation/ but otherwise LGTM.

I fixed (most of) that in the previous version but my fix was lost.

Thanks for the fixups, Andrew.

I still see a few 'zone->lock' references in Documentation remain on mm-new. This patch cleans them up, as noted by Vlastimil.

I'm happy to adjust this patch if anything else needs attention.

From 9142d5a8b60038fa424a6033253960682e5a51f4 Mon Sep 17 00:00:00 2001
From: Dmitry Ilvokhin <[email protected]>
Date: Tue, 3 Mar 2026 06:13:13 -0800
Subject: [PATCH] mm: fix remaining zone->lock references

Signed-off-by Dmitry Ilvokhin <[email protected]>

---
 Documentation/mm/physical_memory.rst | 4 ++--
 Documentation/trace/events-kmem.rst  | 8 ++++----
 2 files changed, 6 insertions(+), 6 deletions(-)

Documentation/mm/physical_memory.rst +0 -0

index b76183545e5b..e344f93515b6 100644

Documentation/mm/physical_memory.rst General · line 503

Quoted 5 lines

Documentation/mm/physical_memory.rst +1 -1

@@ -500,11 +500,11 @@ General
 ``nr_isolate_pageblock``
   Number of isolated pageblocks. It is used to solve incorrect freepage counting
   problem due to racy retrieving migratetype of pageblock. Protected by
-  ``zone->lock``. Defined only when ``CONFIG_MEMORY_ISOLATION`` is enabled.
+  ``zone_lock``. Defined only when ``CONFIG_MEMORY_ISOLATION`` is enabled.

Dmitry's original patch [1] was doing 's/zone->lock/zone->_lock/', which aligns to my expectation. But this patch is doing 's/zone->lock/zone_lock/'. Same for the rest of this patch.

Quoted 6 lines

I was initially thinking this is just a mistake, but I also found Andrew is doing same change [2], so I'm bit confused. Is this an intentional change?

[1] https://lore.kernel.org/d61500c5784c64e971f4d328c57639303c475f81.1772206930.git.d@ilvokhin.com
[2] https://lore.kernel.org/[email protected]

Good catch, thanks for pointing this out, SJ.

Quoted 7 lines

Originally the mechanical rename was indeed zone->lock -> zone->_lock. However, in Documentation I intentionally switched references to zone_lock instead of zone->_lock. The reasoning is that _lock is now an internal implementation detail, and direct access is discouraged. The intended interface is via the zone_lock_*() / zone_unlock_*() wrappers, so referencing zone_lock in documentation felt more appropriate than mentioning the private struct field (zone->_lock).

Thank you for this nice and kind clarification, Dmitry! I agree mentioning zone_[un]lock_*() helpers instead of the hidden member (zone->_lock) can be better.

But, I'm concerned if people like me might not aware the intention under 'zone_lock'. If there is a well-known convention that allows people to know it is for 'zone_[un]lock_*()' helpers, making it more clear would be nice, in my humble opinion. If there is such a convention but I'm just missing it, please ignore. If I'm not, for eaxmaple,

"protected by ``zone->lock``" could be re-wrote to "protected by ``zone_[un]lock_*()`` locking helpers" or, "protected by zone lock helper functions (``zone_[un]lock_*()``)" ?

Quoted 5 lines

That said, I agree this creates inconsistency with the mechanical rename, and I'm happy to adjust either way: either consistently refer to the wrapper API, or keep documentation aligned with zone->_lock.

Quoted 2 lines

I slightly prefer referring to the wrapper API, but don't have a strong preference as long as we're consistent.

I also think both approaches are good. But for the wrapper approach, I think giving more contexts rather than just ``zone_lock`` to readers would be nice.

Quoted 100 lines · SeongJae Park

Quoted 68 lines · On Wed, 4 Mar 2026 13:01:45 +0000 Dmitry Ilvokhin <[email protected]> wrote:

Quoted 58 lines · SeongJae Park

Quoted 46 lines · On Tue, 3 Mar 2026 14:25:55 +0000 Dmitry Ilvokhin <[email protected]> wrote:

Quoted 16 lines · Andrew Morton

Quoted 14 lines · On Mon, 2 Mar 2026 15:10:03 +0100 "Vlastimil Babka (SUSE)" <[email protected]>…

Quoted 12 lines · Dmitry Ilvokhin

This intentionally breaks direct users of zone->lock at compile time so all call sites are converted to the zone lock wrappers. Without the rename, present and future out-of-tree code could continue using spin_lock(&zone->lock) and bypass the wrappers and tracing infrastructure.

No functional change intended.

Suggested-by Andrew Morton <[email protected]>

Signed-off-by Dmitry Ilvokhin <[email protected]>

Acked-by Shakeel Butt <[email protected]>

Acked-by SeongJae Park <[email protected]>

Quoted 5 lines

Quoted 3 lines

I see some more instances of 'zone->lock' in comments in include/linux/mmzone.h and under Documentation/ but otherwise LGTM.

I fixed (most of) that in the previous version but my fix was lost.

Thanks for the fixups, Andrew.

I still see a few 'zone->lock' references in Documentation remain on mm-new. This patch cleans them up, as noted by Vlastimil.

I'm happy to adjust this patch if anything else needs attention.

From 9142d5a8b60038fa424a6033253960682e5a51f4 Mon Sep 17 00:00:00 2001
From: Dmitry Ilvokhin <[email protected]>
Date: Tue, 3 Mar 2026 06:13:13 -0800
Subject: [PATCH] mm: fix remaining zone->lock references

Signed-off-by Dmitry Ilvokhin <[email protected]>

---
 Documentation/mm/physical_memory.rst | 4 ++--
 Documentation/trace/events-kmem.rst  | 8 ++++----
 2 files changed, 6 insertions(+), 6 deletions(-)

Documentation/mm/physical_memory.rst +0 -0

index b76183545e5b..e344f93515b6 100644

Documentation/mm/physical_memory.rst General · line 503

Quoted 5 lines

Documentation/mm/physical_memory.rst +1 -1

@@ -500,11 +500,11 @@ General
 ``nr_isolate_pageblock``
   Number of isolated pageblocks. It is used to solve incorrect freepage counting
   problem due to racy retrieving migratetype of pageblock. Protected by
-  ``zone->lock``. Defined only when ``CONFIG_MEMORY_ISOLATION`` is enabled.
+  ``zone_lock``. Defined only when ``CONFIG_MEMORY_ISOLATION`` is enabled.

Dmitry's original patch [1] was doing 's/zone->lock/zone->_lock/', which aligns to my expectation. But this patch is doing 's/zone->lock/zone_lock/'. Same for the rest of this patch.

Quoted 6 lines

I was initially thinking this is just a mistake, but I also found Andrew is doing same change [2], so I'm bit confused. Is this an intentional change?

[1] https://lore.kernel.org/d61500c5784c64e971f4d328c57639303c475f81.1772206930.git.d@ilvokhin.com
[2] https://lore.kernel.org/[email protected]

Good catch, thanks for pointing this out, SJ.

Quoted 7 lines

Originally the mechanical rename was indeed zone->lock -> zone->_lock. However, in Documentation I intentionally switched references to zone_lock instead of zone->_lock. The reasoning is that _lock is now an internal implementation detail, and direct access is discouraged. The intended interface is via the zone_lock_*() / zone_unlock_*() wrappers, so referencing zone_lock in documentation felt more appropriate than mentioning the private struct field (zone->_lock).

Thank you for this nice and kind clarification, Dmitry! I agree mentioning zone_[un]lock_*() helpers instead of the hidden member (zone->_lock) can be better.

But, I'm concerned if people like me might not aware the intention under 'zone_lock'. If there is a well-known convention that allows people to know it is for 'zone_[un]lock_*()' helpers, making it more clear would be nice, in my humble opinion. If there is such a convention but I'm just missing it, please ignore. If I'm not, for eaxmaple,

"protected by ``zone->lock``" could be re-wrote to "protected by ``zone_[un]lock_*()`` locking helpers" or, "protected by zone lock helper functions (``zone_[un]lock_*()``)" ?

Quoted 7 lines

That said, I agree this creates inconsistency with the mechanical rename, and I'm happy to adjust either way: either consistently refer to the wrapper API, or keep documentation aligned with zone->_lock.

I slightly prefer referring to the wrapper API, but don't have a strong preference as long as we're consistent.

Quoted 2 lines

I also think both approaches are good. But for the wrapper approach, I think giving more contexts rather than just ``zone_lock`` to readers would be nice.

Grep tells me that we also have comments mentioning simply "zone lock", btw. And it's also a term used often in informal conversations. Maybe we could just standardize on that in comments/documentations as it's easier to read. Discovering that the field is called _lock and that wrappers should be used, is hopefully not that difficult.

Quoted 100 lines · SeongJae Park

Quoted 68 lines · On Wed, 4 Mar 2026 13:01:45 +0000 Dmitry Ilvokhin <[email protected]> wrote:

Quoted 58 lines · SeongJae Park

Quoted 46 lines · On Tue, 3 Mar 2026 14:25:55 +0000 Dmitry Ilvokhin <[email protected]> wrote:

Quoted 16 lines · Andrew Morton

Quoted 14 lines · On Mon, 2 Mar 2026 15:10:03 +0100 "Vlastimil Babka (SUSE)" <[email protected]>…

Quoted 12 lines · Dmitry Ilvokhin

This intentionally breaks direct users of zone->lock at compile time so all call sites are converted to the zone lock wrappers. Without the rename, present and future out-of-tree code could continue using spin_lock(&zone->lock) and bypass the wrappers and tracing infrastructure.

No functional change intended.

Suggested-by Andrew Morton <[email protected]>

Signed-off-by Dmitry Ilvokhin <[email protected]>

Acked-by Shakeel Butt <[email protected]>

Acked-by SeongJae Park <[email protected]>

Quoted 5 lines

Quoted 3 lines

I see some more instances of 'zone->lock' in comments in include/linux/mmzone.h and under Documentation/ but otherwise LGTM.

I fixed (most of) that in the previous version but my fix was lost.

Thanks for the fixups, Andrew.

I still see a few 'zone->lock' references in Documentation remain on mm-new. This patch cleans them up, as noted by Vlastimil.

I'm happy to adjust this patch if anything else needs attention.

From 9142d5a8b60038fa424a6033253960682e5a51f4 Mon Sep 17 00:00:00 2001
From: Dmitry Ilvokhin <[email protected]>
Date: Tue, 3 Mar 2026 06:13:13 -0800
Subject: [PATCH] mm: fix remaining zone->lock references

Signed-off-by Dmitry Ilvokhin <[email protected]>

---
 Documentation/mm/physical_memory.rst | 4 ++--
 Documentation/trace/events-kmem.rst  | 8 ++++----
 2 files changed, 6 insertions(+), 6 deletions(-)

Documentation/mm/physical_memory.rst +0 -0

index b76183545e5b..e344f93515b6 100644

Documentation/mm/physical_memory.rst General · line 503

Quoted 5 lines

Documentation/mm/physical_memory.rst +1 -1

@@ -500,11 +500,11 @@ General
 ``nr_isolate_pageblock``
   Number of isolated pageblocks. It is used to solve incorrect freepage counting
   problem due to racy retrieving migratetype of pageblock. Protected by
-  ``zone->lock``. Defined only when ``CONFIG_MEMORY_ISOLATION`` is enabled.
+  ``zone_lock``. Defined only when ``CONFIG_MEMORY_ISOLATION`` is enabled.

Dmitry's original patch [1] was doing 's/zone->lock/zone->_lock/', which aligns to my expectation. But this patch is doing 's/zone->lock/zone_lock/'. Same for the rest of this patch.

Quoted 6 lines

I was initially thinking this is just a mistake, but I also found Andrew is doing same change [2], so I'm bit confused. Is this an intentional change?

[1] https://lore.kernel.org/d61500c5784c64e971f4d328c57639303c475f81.1772206930.git.d@ilvokhin.com
[2] https://lore.kernel.org/[email protected]

Good catch, thanks for pointing this out, SJ.

Quoted 7 lines

Originally the mechanical rename was indeed zone->lock -> zone->_lock. However, in Documentation I intentionally switched references to zone_lock instead of zone->_lock. The reasoning is that _lock is now an internal implementation detail, and direct access is discouraged. The intended interface is via the zone_lock_*() / zone_unlock_*() wrappers, so referencing zone_lock in documentation felt more appropriate than mentioning the private struct field (zone->_lock).

Thank you for this nice and kind clarification, Dmitry! I agree mentioning zone_[un]lock_*() helpers instead of the hidden member (zone->_lock) can be better.

But, I'm concerned if people like me might not aware the intention under 'zone_lock'. If there is a well-known convention that allows people to know it is for 'zone_[un]lock_*()' helpers, making it more clear would be nice, in my humble opinion. If there is such a convention but I'm just missing it, please ignore. If I'm not, for eaxmaple,

"protected by ``zone->lock``" could be re-wrote to "protected by ``zone_[un]lock_*()`` locking helpers" or, "protected by zone lock helper functions (``zone_[un]lock_*()``)" ?

Quoted 7 lines

That said, I agree this creates inconsistency with the mechanical rename, and I'm happy to adjust either way: either consistently refer to the wrapper API, or keep documentation aligned with zone->_lock.

I slightly prefer referring to the wrapper API, but don't have a strong preference as long as we're consistent.

Quoted 2 lines

I also think both approaches are good. But for the wrapper approach, I think giving more contexts rather than just ``zone_lock`` to readers would be nice.

Grep tells me that we also have comments mentioning simply "zone lock", btw. And it's also a term used often in informal conversations. Maybe we could just standardize on that in comments/documentations as it's easier to read. Discovering that the field is called _lock and that wrappers should be used, is hopefully not that difficult.

Quoted 101 lines · Vlastimil Babka (SUSE)

Quoted 100 lines · SeongJae Park

Quoted 68 lines · On Wed, 4 Mar 2026 13:01:45 +0000 Dmitry Ilvokhin <[email protected]> wrote:

Quoted 58 lines · SeongJae Park

Quoted 46 lines · On Tue, 3 Mar 2026 14:25:55 +0000 Dmitry Ilvokhin <[email protected]> wrote:

Quoted 16 lines · Andrew Morton

Quoted 14 lines · On Mon, 2 Mar 2026 15:10:03 +0100 "Vlastimil Babka (SUSE)" <[email protected]>…

Quoted 12 lines · Dmitry Ilvokhin

This intentionally breaks direct users of zone->lock at compile time so all call sites are converted to the zone lock wrappers. Without the rename, present and future out-of-tree code could continue using spin_lock(&zone->lock) and bypass the wrappers and tracing infrastructure.

No functional change intended.

Suggested-by Andrew Morton <[email protected]>

Signed-off-by Dmitry Ilvokhin <[email protected]>

Acked-by Shakeel Butt <[email protected]>

Acked-by SeongJae Park <[email protected]>

Quoted 5 lines

Quoted 3 lines

I see some more instances of 'zone->lock' in comments in include/linux/mmzone.h and under Documentation/ but otherwise LGTM.

I fixed (most of) that in the previous version but my fix was lost.

Thanks for the fixups, Andrew.

I still see a few 'zone->lock' references in Documentation remain on mm-new. This patch cleans them up, as noted by Vlastimil.

I'm happy to adjust this patch if anything else needs attention.

From 9142d5a8b60038fa424a6033253960682e5a51f4 Mon Sep 17 00:00:00 2001
From: Dmitry Ilvokhin <[email protected]>
Date: Tue, 3 Mar 2026 06:13:13 -0800
Subject: [PATCH] mm: fix remaining zone->lock references

Signed-off-by Dmitry Ilvokhin <[email protected]>

---
 Documentation/mm/physical_memory.rst | 4 ++--
 Documentation/trace/events-kmem.rst  | 8 ++++----
 2 files changed, 6 insertions(+), 6 deletions(-)

Documentation/mm/physical_memory.rst +0 -0

index b76183545e5b..e344f93515b6 100644

Documentation/mm/physical_memory.rst General · line 503

Quoted 5 lines

Documentation/mm/physical_memory.rst +1 -1

@@ -500,11 +500,11 @@ General
 ``nr_isolate_pageblock``
   Number of isolated pageblocks. It is used to solve incorrect freepage counting
   problem due to racy retrieving migratetype of pageblock. Protected by
-  ``zone->lock``. Defined only when ``CONFIG_MEMORY_ISOLATION`` is enabled.
+  ``zone_lock``. Defined only when ``CONFIG_MEMORY_ISOLATION`` is enabled.

Dmitry's original patch [1] was doing 's/zone->lock/zone->_lock/', which aligns to my expectation. But this patch is doing 's/zone->lock/zone_lock/'. Same for the rest of this patch.

Quoted 6 lines

I was initially thinking this is just a mistake, but I also found Andrew is doing same change [2], so I'm bit confused. Is this an intentional change?

[1] https://lore.kernel.org/d61500c5784c64e971f4d328c57639303c475f81.1772206930.git.d@ilvokhin.com
[2] https://lore.kernel.org/[email protected]

Good catch, thanks for pointing this out, SJ.

Quoted 7 lines

Originally the mechanical rename was indeed zone->lock -> zone->_lock. However, in Documentation I intentionally switched references to zone_lock instead of zone->_lock. The reasoning is that _lock is now an internal implementation detail, and direct access is discouraged. The intended interface is via the zone_lock_*() / zone_unlock_*() wrappers, so referencing zone_lock in documentation felt more appropriate than mentioning the private struct field (zone->_lock).

Thank you for this nice and kind clarification, Dmitry! I agree mentioning zone_[un]lock_*() helpers instead of the hidden member (zone->_lock) can be better.

But, I'm concerned if people like me might not aware the intention under 'zone_lock'. If there is a well-known convention that allows people to know it is for 'zone_[un]lock_*()' helpers, making it more clear would be nice, in my humble opinion. If there is such a convention but I'm just missing it, please ignore. If I'm not, for eaxmaple,

"protected by ``zone->lock``" could be re-wrote to "protected by ``zone_[un]lock_*()`` locking helpers" or, "protected by zone lock helper functions (``zone_[un]lock_*()``)" ?

Quoted 7 lines

That said, I agree this creates inconsistency with the mechanical rename, and I'm happy to adjust either way: either consistently refer to the wrapper API, or keep documentation aligned with zone->_lock.

I slightly prefer referring to the wrapper API, but don't have a strong preference as long as we're consistent.

Quoted 8 lines

Quoted 2 lines

I also think both approaches are good. But for the wrapper approach, I think giving more contexts rather than just ``zone_lock`` to readers would be nice.

Grep tells me that we also have comments mentioning simply "zone lock", btw. And it's also a term used often in informal conversations. Maybe we could just standardize on that in comments/documentations as it's easier to read. Discovering that the field is called _lock and that wrappers should be used, is hopefully not that difficult.

Thanks for the suggestion, Vlastimil. That sounds reasonable to me as well. I'll update the comments and documentation to consistently use "zone lock".

Following the suggestion from SJ and Vlastimil, I prepared fixup to standardize documentation and comments on the term "zone lock".

The patch is based on top of the current mm-new.

Andrew, please let me know if you would prefer a respin of the series instead.

From 267cda3e0e160f97b346009bc48819bfeed92e52 Mon Sep 17 00:00:00 2001
From: Dmitry Ilvokhin <[email protected]>
Date: Thu, 5 Mar 2026 10:36:17 -0800
Subject: [PATCH] mm: documentation: standardize on "zone lock" terminology

During review of the zone lock tracing series it was suggested to standardize documentation and comments on the term "zone lock" instead of using zone_lock or referring to the internal field zone->_lock.

Update references accordingly.

Signed-off-by Dmitry Ilvokhin <[email protected]>

Quoted 111 lines · Dmitry Ilvokhin

Quoted 101 lines · Vlastimil Babka (SUSE)

Quoted 100 lines · SeongJae Park

Quoted 68 lines · On Wed, 4 Mar 2026 13:01:45 +0000 Dmitry Ilvokhin <[email protected]> wrote:

Quoted 58 lines · SeongJae Park

Quoted 46 lines · On Tue, 3 Mar 2026 14:25:55 +0000 Dmitry Ilvokhin <[email protected]> wrote:

Quoted 16 lines · Andrew Morton

Quoted 14 lines · On Mon, 2 Mar 2026 15:10:03 +0100 "Vlastimil Babka (SUSE)" <[email protected]>…

Quoted 12 lines · Dmitry Ilvokhin

This intentionally breaks direct users of zone->lock at compile time so all call sites are converted to the zone lock wrappers. Without the rename, present and future out-of-tree code could continue using spin_lock(&zone->lock) and bypass the wrappers and tracing infrastructure.

No functional change intended.

Suggested-by Andrew Morton <[email protected]>

Signed-off-by Dmitry Ilvokhin <[email protected]>

Acked-by Shakeel Butt <[email protected]>

Acked-by SeongJae Park <[email protected]>

Quoted 5 lines

Quoted 3 lines

I see some more instances of 'zone->lock' in comments in include/linux/mmzone.h and under Documentation/ but otherwise LGTM.

I fixed (most of) that in the previous version but my fix was lost.

Thanks for the fixups, Andrew.

I still see a few 'zone->lock' references in Documentation remain on mm-new. This patch cleans them up, as noted by Vlastimil.

I'm happy to adjust this patch if anything else needs attention.

From 9142d5a8b60038fa424a6033253960682e5a51f4 Mon Sep 17 00:00:00 2001
From: Dmitry Ilvokhin <[email protected]>
Date: Tue, 3 Mar 2026 06:13:13 -0800
Subject: [PATCH] mm: fix remaining zone->lock references

Signed-off-by Dmitry Ilvokhin <[email protected]>

---
 Documentation/mm/physical_memory.rst | 4 ++--
 Documentation/trace/events-kmem.rst  | 8 ++++----
 2 files changed, 6 insertions(+), 6 deletions(-)

Documentation/mm/physical_memory.rst +0 -0

index b76183545e5b..e344f93515b6 100644

Documentation/mm/physical_memory.rst General · line 503

Quoted 5 lines

Documentation/mm/physical_memory.rst +1 -1

@@ -500,11 +500,11 @@ General
 ``nr_isolate_pageblock``
   Number of isolated pageblocks. It is used to solve incorrect freepage counting
   problem due to racy retrieving migratetype of pageblock. Protected by
-  ``zone->lock``. Defined only when ``CONFIG_MEMORY_ISOLATION`` is enabled.
+  ``zone_lock``. Defined only when ``CONFIG_MEMORY_ISOLATION`` is enabled.

Dmitry's original patch [1] was doing 's/zone->lock/zone->_lock/', which aligns to my expectation. But this patch is doing 's/zone->lock/zone_lock/'. Same for the rest of this patch.

Quoted 6 lines

I was initially thinking this is just a mistake, but I also found Andrew is doing same change [2], so I'm bit confused. Is this an intentional change?

[1] https://lore.kernel.org/d61500c5784c64e971f4d328c57639303c475f81.1772206930.git.d@ilvokhin.com
[2] https://lore.kernel.org/[email protected]

Good catch, thanks for pointing this out, SJ.

Quoted 7 lines

Originally the mechanical rename was indeed zone->lock -> zone->_lock. However, in Documentation I intentionally switched references to zone_lock instead of zone->_lock. The reasoning is that _lock is now an internal implementation detail, and direct access is discouraged. The intended interface is via the zone_lock_*() / zone_unlock_*() wrappers, so referencing zone_lock in documentation felt more appropriate than mentioning the private struct field (zone->_lock).

Thank you for this nice and kind clarification, Dmitry! I agree mentioning zone_[un]lock_*() helpers instead of the hidden member (zone->_lock) can be better.

But, I'm concerned if people like me might not aware the intention under 'zone_lock'. If there is a well-known convention that allows people to know it is for 'zone_[un]lock_*()' helpers, making it more clear would be nice, in my humble opinion. If there is such a convention but I'm just missing it, please ignore. If I'm not, for eaxmaple,

"protected by ``zone->lock``" could be re-wrote to "protected by ``zone_[un]lock_*()`` locking helpers" or, "protected by zone lock helper functions (``zone_[un]lock_*()``)" ?

Quoted 7 lines

That said, I agree this creates inconsistency with the mechanical rename, and I'm happy to adjust either way: either consistently refer to the wrapper API, or keep documentation aligned with zone->_lock.

I slightly prefer referring to the wrapper API, but don't have a strong preference as long as we're consistent.

Quoted 8 lines

Quoted 2 lines

I also think both approaches are good. But for the wrapper approach, I think giving more contexts rather than just ``zone_lock`` to readers would be nice.

Grep tells me that we also have comments mentioning simply "zone lock", btw. And it's also a term used often in informal conversations. Maybe we could just standardize on that in comments/documentations as it's easier to read. Discovering that the field is called _lock and that wrappers should be used, is hopefully not that difficult.

Quoted 3 lines

Thanks for the suggestion, Vlastimil. That sounds reasonable to me as well. I'll update the comments and documentation to consistently use "zone lock".

Following the suggestion from SJ and Vlastimil, I prepared fixup to standardize documentation and comments on the term "zone lock".

The patch is based on top of the current mm-new.

Andrew, please let me know if you would prefer a respin of the series instead.

From 267cda3e0e160f97b346009bc48819bfeed92e52 Mon Sep 17 00:00:00 2001
From: Dmitry Ilvokhin <[email protected]>
Date: Thu, 5 Mar 2026 10:36:17 -0800
Subject: [PATCH] mm: documentation: standardize on "zone lock" terminology

During review of the zone lock tracing series it was suggested to standardize documentation and comments on the term "zone lock" instead of using zone_lock or referring to the internal field zone->_lock.

Update references accordingly.

Signed-off-by Dmitry Ilvokhin <[email protected]>

This intentionally breaks direct users of zone->lock at compile time so all call sites are converted to the zone lock wrappers. Without the rename, present and future out-of-tree code could continue using spin_lock(&zone->lock) and bypass the wrappers and tracing infrastructure.

No functional change intended.

Suggested-by Andrew Morton <[email protected]>

Signed-off-by Dmitry Ilvokhin <[email protected]>

Acked-by Shakeel Butt <[email protected]>

Acked-by SeongJae Park <[email protected]>

---
 include/linux/mmzone.h      |  7 +++++--
 include/linux/mmzone_lock.h | 12 ++++++------
 mm/compaction.c             |  4 ++--
 mm/internal.h               |  2 +-
 mm/page_alloc.c             | 16 ++++++++--------
 mm/page_isolation.c         |  4 ++--
 mm/page_owner.c             |  2 +-
 7 files changed, 25 insertions(+), 22 deletions(-)

include/linux/mmzone.h +0 -0

index 3e51190a55e4..32bca655fce5 100644

include/linux/mmzone_lock.h +7 -1

 } while (0)
 
 #define zone_trylock_irqsave(zone, flags)			\
 ({								\
-	spin_trylock_irqsave(&(zone)->_lock, flags);		\
+	bool success;						\
+								\
+	__zone_lock_trace_start_locking(zone);			\
+	success = spin_trylock_irqsave(&(zone)->_lock, flags);	\
+	__zone_lock_trace_acquire_returned(zone, success);	\
+	success;						\
 })
 
 static inline void zone_unlock_irqrestore(struct zone *zone, unsigned long flags)
 {
+	__zone_lock_trace_released(zone);

include/linux/mmzone_lock.h static inline void zone_lock_init(struct zone *zone) · line 66

Quoted 11 lines · On Fri, 27 Feb 2026 16:00:27 +0000 Dmitry Ilvokhin <[email protected]> wrote:

static inline void zone_lock_init(struct zone *zone) {

include/linux/mmzone_lock.h +4 -0

@@ -12,26 +59,41 @@ static inline void zone_lock_init(struct zone *zone)
 
 #define zone_lock_irqsave(zone, flags)				\
 do {								\
+	bool success = true;					\
+								\
+	__zone_lock_trace_start_locking(zone);			\
 	spin_lock_irqsave(&(zone)->_lock, flags);		\
+	__zone_lock_trace_acquire_returned(zone, success);	\

Why the "success" variable and not just:

	__zone_lock_trace_acquire_returned(zone, true);

?

Add tracepoint instrumentation to zone lock acquire/release operations via the previously introduced wrappers.

The implementation follows the mmap_lock tracepoint pattern: a lightweight inline helper checks whether the tracepoint is enabled and calls into an out-of-line helper when tracing is active. When CONFIG_TRACING is disabled, helpers compile to empty inline stubs.

The fast path is unaffected when tracing is disabled.

Signed-off-by Dmitry Ilvokhin <[email protected]>

Acked-by Shakeel Butt <[email protected]>

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.

Quoted 18 lines · Dmitry Ilvokhin

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.

Quoted 2 lines

This patch series adds dedicated tracepoint instrumentation to zone lock, following the existing mmap_lock tracing model.

I don't like this at all. We have CONFIG_LOCK_STAT. That should be improved insted of coming up with one-offs for every single lock that someone deems "special".

Quoted 7 lines · Matthew Wilcox

Quoted 2 lines · Dmitry Ilvokhin

This patch series adds dedicated tracepoint instrumentation to zone lock, following the existing mmap_lock tracing model.

I don't like this at all. We have CONFIG_LOCK_STAT. That should be improved insted of coming up with one-offs for every single lock that someone deems "special".

Thanks for the feedback, Matthew.

CONFIG_LOCK_STAT provides useful statistics, but it is primarily a debug facility and is generally too heavyweight for the production environments.

The motivation for this series was to provide lightweight observability for the zone lock in production workloads.

I agree that improving generic lock instrumentation would be preferable. I did consider whether something similar could be done generically for spinlocks, but the unlock path there is typically just a single atomic store, so adding generic lightweight instrumentation without affecting the fast path is difficult.

In parallel, I've been experimenting with improving observability for sleepable locks by adding a contended_release tracepoint, which would allow correlating lock holders and waiters in a more generic way. I've posted an RFC here:

https://lore.kernel.org/all/[email protected]/

I'd appreciate feedback on whether that direction makes sense for improving the generic lock tracing infrastructure.

Quoted 3 lines

CONFIG_LOCK_STAT provides useful statistics, but it is primarily a debug facility and is generally too heavyweight for the production environments.

Yes, agreed. I think that is what needs to change.

The biggest issue with making a generic light weight LOCK_STAT is that locks are extremely optimized. Any addition of generic lock encoding will cause a noticeable overhead when compiled in, even when disabled.

The other issue is the data we store for the lock. A lock is usually just a word (or long) in size, embedded in a structure. LOCKDEP and LOCK_STAT adds a key per lock. This increases the data size of the kernel.

Quoted 3 lines · Steven Rostedt

The biggest issue with making a generic light weight LOCK_STAT is that locks are extremely optimized. Any addition of generic lock encoding will cause a noticeable overhead when compiled in, even when disabled.

I'm not sure that's true. Taking the current Debian kernel config leads to a "call" instruction to acquire a spinlock:

void __insert_inode_hash(struct inode *inode, unsigned long hashval)

{
        struct hlist_head *b = inode_hashtable + hash(inode->i_sb, hashval);

        spin_lock(&inode_hash_lock);
        spin_lock(&inode->i_lock);
        hlist_add_head_rcu(&inode->i_hash, b);
        spin_unlock(&inode->i_lock);
        spin_unlock(&inode_hash_lock);
}

compiles to:

[...]

     280:       23 35 00 00 00 00       and    0x0(%rip),%esi        # 286 <__insert_inode_hash+0x56>
                        282: R_X86_64_PC32      .data..ro_after_init+0x10
     286:       48 8d 2c f0             lea    (%rax,%rsi,8),%rbp
     28a:       e8 00 00 00 00          call   28f <__insert_inode_hash+0x5f>
                        28b: R_X86_64_PLT32     _raw_spin_lock-0x4
     28f:       4c 89 e7                mov    %r12,%rdi
     292:       e8 00 00 00 00          call   297 <__insert_inode_hash+0x67>
                        293: R_X86_64_PLT32     _raw_spin_lock-0x4

[...]

(The spinlock code is too complex for me to follow what config options influence whether it's a function call; you probably have enough of it in your head that you'd know)

Quoted 4 lines

The other issue is the data we store for the lock. A lock is usually just a word (or long) in size, embedded in a structure. LOCKDEP and LOCK_STAT adds a key per lock. This increases the data size of the kernel.

It does, but perhaps for a light weight lockstat, we could do better than that. For example it could use the return address to look up which lock is being accessed rather than embedding a key in each lock.

A possible generic solution is a trace_contended_release() for spin locks, for example:

    if (trace_contended_release_enabled() &&
        atomic_read(&lock->val) & ~_Q_LOCKED_MASK)
        trace_contended_release(lock);

This might work on x86, but could increase code size and regress performance on arches where spin_unlock() is inlined, such as arm64 under !PREEMPTION.

On Mon, Mar 16, 2026 at 05:40:50PM +0000, Dmitry Ilvokhin wrote:

[...]

Quoted 10 lines

A possible generic solution is a trace_contended_release() for spin locks, for example:

    if (trace_contended_release_enabled() &&
        atomic_read(&lock->val) & ~_Q_LOCKED_MASK)
        trace_contended_release(lock);

This might work on x86, but could increase code size and regress performance on arches where spin_unlock() is inlined, such as arm64 under !PREEMPTION.

I took a stab at this idea and submitted an RFC [1].

The implementation builds on your earlier observation from Matthew that _raw_spin_unlock() is not inlined in most configurations. In those cases, when the tracepoint is disabled, this adds a single NOP on the fast path, with the conditional check staying out of line. The measured text size increase in this configuration is +983 bytes.

For configurations where _raw_spin_unlock() is inlined, the instrumentation does increase code size more noticeably (+71 KB in my measurements), since the check and out of line call is replicated at each call site.

This provides a generic release-side signal for contended locks,
allowing: correlation of lock holders with waiters and measurement of contended hold times

This RFC addressing the same visibility gap without introducing per-lock instrumentation.

If this tradeoff is acceptable, this could be a generic alternative to lock-specific tracepoints.

[1]: https://lore.kernel.org/all/51aad0415b78c5a39f2029722118fa01eac77538.1773858853.git.d@ilvokhin.com

Quoted 38 lines · On Thu, 19 Mar 2026 13:22:54 +0000 Dmitry Ilvokhin <[email protected]> wrote:

On Mon, Mar 16, 2026 at 05:40:50PM +0000, Dmitry Ilvokhin wrote:

[...]

Quoted 10 lines

A possible generic solution is a trace_contended_release() for spin locks, for example:

    if (trace_contended_release_enabled() &&
        atomic_read(&lock->val) & ~_Q_LOCKED_MASK)
        trace_contended_release(lock);

This might work on x86, but could increase code size and regress performance on arches where spin_unlock() is inlined, such as arm64 under !PREEMPTION.

I took a stab at this idea and submitted an RFC [1].

The implementation builds on your earlier observation from Matthew that _raw_spin_unlock() is not inlined in most configurations. In those cases, when the tracepoint is disabled, this adds a single NOP on the fast path, with the conditional check staying out of line. The measured text size increase in this configuration is +983 bytes.

For configurations where _raw_spin_unlock() is inlined, the instrumentation does increase code size more noticeably (+71 KB in my measurements), since the check and out of line call is replicated at each call site.

This provides a generic release-side signal for contended locks,
allowing: correlation of lock holders with waiters and measurement of contended hold times

This RFC addressing the same visibility gap without introducing per-lock instrumentation.

If this tradeoff is acceptable, this could be a generic alternative to lock-specific tracepoints.

Quoted 1 line

[1]: https://lore.kernel.org/all/51aad0415b78c5a39f2029722118fa01eac77538.1773858853.git.d@ilvokhin.com

That submission has met a disappointing response.

How should I proceed with this series "mm: zone lock tracepoint instrumentation"? It's not urgent so I'm inclined to put this on hold while you pursue "locking: Add contended_release tracepoint to spinning locks"?

Please send that v2 sometime and hopefully Steven can help push it along?

Quoted 1 line

Please send that v2 sometime and hopefully Steven can help push it along?

I'll send the next version of the generic locking series soon. Any help in pushing it along would be appreciated.