Re: [PATCH] mm: kmemleak: drop kmemleak_lock in scan_block() when it is contended

[Andrew Morton <akpm@linux-foundation.org>]

On Thu, 12 Nov 2026 15:51:19 +0000 Catalin Marinas <catalin.marinas@arm.com> wrote:

> On Thu, Nov 12, 2026 at 03:48:01AM -0800, Breno Leitao wrote:
> > kernel_lock is a damn hot lock, used on allocations, free, NET_RX, etc.
> 
> Nit: s/kernel_lock/kmemleak_lock/

aww man, I had flashbacks.

Then came along
https://github.com/torvalds/linux/commit/4ba8216cd90560bc402f52076f64d8546e8aefcb

things were so much simpler in those days.

> > It is also used on the scan, so, while scanning, most of the system is
> > mostly waiting for the lock.
> > 
> > On meta fleet, this is, by far, the most contented lock. This is not
> > a big deal, because very few hosts run with kmemleak enabled, but,
> > I think we can do better here.
> > 
> > scan_block() takes kmemleak_lock once per block and keeps it, with
> > interrupts disabled, for up to MAX_SCAN_SIZE bytes: 512 words, each
> > needing up to two object tree lookups. Every allocation and free in the
> > system needs the same lock to insert or remove its object, so each of
> > them can wait for a whole block.
> > 
> > Keep taking the lock once per block, but in auto scan mode, check every
> > 64 words whether anybody is waiting for it and, if so, breathe (aka
> > release it and take it again so that the waiters go first)
> > 
> > Releasing the lock is seems safe because it only keeps the object trees
> 
> Nit: s/is//

De-nitted and grabbed, thanks.