[PATCH v3 0/8] mm: use spinlock guards for zone lock

Dmitry Ilvokhin posted 8 patches 1 month, 2 weeks ago
mm/page_alloc.c     | 53 ++++++++++++-----------------------
mm/page_isolation.c | 67 +++++++++++++++++++--------------------------
2 files changed, 45 insertions(+), 75 deletions(-)
[PATCH v3 0/8] mm: use spinlock guards for zone lock
Posted by Dmitry Ilvokhin 1 month, 2 weeks ago
This series uses spinlock guard for zone lock across several mm
functions to replace explicit lock/unlock patterns with automatic
scope-based cleanup.

This simplifies the control flow by removing 'flags' variables, goto
labels, and redundant unlock calls.

Patches are ordered by decreasing value. The first six patches simplify
the control flow by removing gotos, multiple unlock paths, or 'ret'
variables. The last two are simpler lock/unlock pair conversions that
only remove 'flags' and can be dropped if considered unnecessary churn.

Binary size increase is +39 bytes, with Peter Zijlstra's fix for guards
[1] applied (already in mm-stable). This is due to the compiler not
being able to deduplicate epilogue and eliminate redundant NULL check.
See discussion [2] for more details. I proposed a patch [3] that fixes
this, but until it is merged we need to assume +39 bytes will stay
(though it is compiler dependent).

Based on mm-stable.

Suggested-by: Steven Rostedt <rostedt@goodmis.org>

v2 -> v3:
- Rebased on top of mm-stable.
- Added Acked-by from Michal.

v1 -> v2:

- Andrew Morton raised concerns about binary size increase in v1.
  Peter Zijlstra has since fixed the underlying issue in the guards
  infrastructure in tip [1].
- Rebased on mm-stable, since the patch this series depended on was
  dropped from mm-new.
- Converted guard(zone_lock_irqsave)(zone) to
  guard(spinlock_irqsave)(&zone->lock).
- Dropped redundant braces in unreserve_highatomic_pageblock()
  (Steven Rostedt)

v2 resend: https://lore.kernel.org/all/cover.1775654118.git.d@ilvokhin.com/
v2: https://lore.kernel.org/all/cover.1774627568.git.d@ilvokhin.com/
v1: https://lore.kernel.org/all/cover.1772811429.git.d@ilvokhin.com/

[1]: https://lore.kernel.org/all/20260309164516.GE606826@noisy.programming.kicks-ass.net/
[2]: https://lore.kernel.org/all/afC5C6fylF4AsITV@shell.ilvokhin.com/
[3]: https://lore.kernel.org/all/20260427165037.205337-1-d@ilvokhin.com/

Dmitry Ilvokhin (8):
  mm: use zone lock guard in reserve_highatomic_pageblock()
  mm: use zone lock guard in unset_migratetype_isolate()
  mm: use zone lock guard in unreserve_highatomic_pageblock()
  mm: use zone lock guard in set_migratetype_isolate()
  mm: use zone lock guard in take_page_off_buddy()
  mm: use zone lock guard in put_page_back_buddy()
  mm: use zone lock guard in free_pcppages_bulk()
  mm: use zone lock guard in __offline_isolated_pages()

 mm/page_alloc.c     | 53 ++++++++++++-----------------------
 mm/page_isolation.c | 67 +++++++++++++++++++--------------------------
 2 files changed, 45 insertions(+), 75 deletions(-)

-- 
2.52.0
Re: [PATCH v3 0/8] mm: use spinlock guards for zone lock
Posted by Andrew Morton 1 month, 2 weeks ago
On Wed, 29 Apr 2026 12:02:05 +0000 Dmitry Ilvokhin <d@ilvokhin.com> wrote:

> This series uses spinlock guard for zone lock across several mm
> functions to replace explicit lock/unlock patterns with automatic
> scope-based cleanup.
> 
> This simplifies the control flow by removing 'flags' variables, goto
> labels, and redundant unlock calls.
> 
> Patches are ordered by decreasing value. The first six patches simplify
> the control flow by removing gotos, multiple unlock paths, or 'ret'
> variables. The last two are simpler lock/unlock pair conversions that
> only remove 'flags' and can be dropped if considered unnecessary churn.
> 
> Binary size increase is +39 bytes, with Peter Zijlstra's fix for guards
> [1] applied (already in mm-stable). This is due to the compiler not
> being able to deduplicate epilogue and eliminate redundant NULL check.
> See discussion [2] for more details. I proposed a patch [3] that fixes
> this, but until it is merged we need to assume +39 bytes will stay
> (though it is compiler dependent).

OK, thanks, I'll queue it up.

Yet again: the question here is whether those who work on this code
like guard(), or would prefer the traditional open-coded locking. 
Michal was an ack, others were silent.