Re: [PATCH 1/8] mm: use zone lock guard in reserve_highatomic_pageblock()

[Andrew Morton]

On Thu, 26 Mar 2026 18:04:35 +0000 Dmitry Ilvokhin <d@xxxxxxxxxxxx> wrote:

> On Fri, Mar 06, 2026 at 09:53:36AM -0800, Andrew Morton wrote:
> > On Fri,  6 Mar 2026 16:05:35 +0000 Dmitry Ilvokhin <d@xxxxxxxxxxxx> wrote:
> > 
> > > Use the newly introduced zone_lock_irqsave lock guard in
> > > reserve_highatomic_pageblock() to replace the explicit lock/unlock and
> > > goto out_unlock pattern with automatic scope-based cleanup.
> > > 
> > > ...
> > >
> > > -	zone_lock_irqsave(zone, flags);
> > > +	guard(zone_lock_irqsave)(zone);
> > 
> > guard() is cute, but this patch adds a little overhead - defconfig
> > page_alloc.o text increases by 32 bytes, presumably all in
> > reserve_highatomic_pageblock().  More instructions, larger cache
> > footprint.
> > 
> > So we're adding a little overhead to every user's Linux machine for all
> > time.  In return for which the developers get a little convenience and
> > maintainability.
> > 
> > Is it worth it?
> 
> Hi Andrew,
> 
> Before respinning this series, I wanted to check if it's worth pursuing.

Probably.  Much depends on the views of the people who regularly work
on this code.  Do they like guard(), or do they prefer the current
explicit open-coded locking?

> At the time you noted the text size increase and questioned whether the
> trade-off makes sense. Since then, the guard infrastructure was fixed by
> Peter, so the code generation situation has improved.

Great.

> The main benefit of the series is still simplifying control flow in
> these functions (removing multiple unlock paths, gotos, etc.).
> 
> Would you be open to this direction if the overhead is negligible, or
> would you prefer to avoid this kind of transformation regardless?
> 
> I can also limit the series to only the more complex cases if that
> helps.

Gee.  I think it would be helpful to prepare a respin which reflects
your current thinking, see what others think.

Please understand that I'm resisting adding new material during this
cycle
(https://lkml.kernel.org/r/20260323202941.08ddf2b0411501cae801ab4c@xxxxxxxxxxxxxxxxxxxx)
so you'd best be targeting 7.1-rc1 at the earliest.

But sending out a new version during this cycle for people to consider
would be a good step.