On Wed, Feb 25, 2026 at 12:12:52PM -0800, Andrew Morton wrote: > On Wed, 25 Feb 2026 14:43:05 +0000 Dmitry Ilvokhin <[email protected]> wrote: > > > Compaction uses compact_lock_irqsave(), which currently operates > > on a raw spinlock_t pointer so that it can be used for both > > zone->lock and lru_lock. Since zone lock operations are now wrapped, > > compact_lock_irqsave() can no longer operate directly on a spinlock_t > > when the lock belongs to a zone. > > > > Introduce struct compact_lock to abstract the underlying lock type. The > > structure carries a lock type enum and a union holding either a zone > > pointer or a raw spinlock_t pointer, and dispatches to the appropriate > > lock/unlock helper. > > It's regrettable that adds overhead - increased .text, increased > instructions. > > Thing is, compact_lock_irqsave() has only two callsites. One knows > that it's dealing with the zone lock, the other knows that it's dealing > with the lruvec lock. > > Would it not be simpler and more efficient to copy/paste/edit two > versions of compact_lock_irqsave()? A compact_zone_lock_irqsave() and a > compact_lruvec_lock_irqsave()? >
Thanks for the feedback, Andrew. My initial goal was to reduce code duplication by keeping the logic centralized, but your rationale makes sense. Given that there are only two call sites and both statically know the lock type, splitting the helper avoids unnecessary abstraction. I'll introduce compact_zone_lock_irqsave() and compact_lruvec_lock_irqsave() in v3.
