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

[Catalin Marinas <catalin.marinas@arm.com>]

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/

> 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//

> stable during each lookup, and scan_block() does not use an object found
> under it past the word being processed.
> 
> Tested in an arm64 KVM guest with 48 vCPUs, KASAN and lockdep, running
> stress-ng sock, fork and dentry workers on 8 CPUs during five scans.
> The kmemleak_lock wait times of the other CPUs, from the lock_contended
> and lock_acquired tracepoints:
> 
>                    average     p99     p99.9
>   no scan            3.7us    <16us    <32us
>   scan, before      15.8us   <256us   <512us
>   scan, after       11.7us    <64us   <256us
> 
> The cost is a slower scan, as the scanner now queues behind the
> waiters: the five scans took 179s instead of 118s.
> 
> This patch does not change interactive users (echo scan > kmemleak in
> debugfs), given current != scan_thread, and scan_breathe() will not be
> called.

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

I looked in the past of getting rid of kmemleak_lock on the scanning
path but I couldn't find an RCU variant of rbtree that guarantees it
won't miss lookups.

-- 
Catalin