Re: [PATCH v4 0/2] mm/vmscan: reduce lru_lock contention via vmstat-derived scan-balance cost

[Andrew Morton]

On Mon, 20 Jul 2026 09:41:21 -0700 Usama Arif <usama.arif@xxxxxxxxx> wrote:

> The anon/file scan balance heuristic in get_scan_count() is fed by two
> scalars in struct lruvec (anon_cost, file_cost) that every reclaim
> producer updates under lruvec->lru_lock. The cost-recording work
> itself is trivial, but it both contends for and contributes to
> contention on lru_lock - which is often a contention point on
> memory-pressured workloads. Specifically:
> 
> - shrink_inactive_list() re-acquires lru_lock at function exit just
>   to call lru_note_cost_unlock_irq().
> - shrink_active_list() does the same after rotation accounting.
> - workingset_refault() takes folio_lruvec_lock_irq() purely to
>   record the refault cost.
> - prepare_scan_control() snapshots anon_cost/file_cost under
>   lru_lock.
> - lru_note_cost_unlock_irq() itself walks parent_lruvec() and
>   re-acquires lru_lock on every ancestor, multiplying the cost
>   of every update by memcg-hierarchy depth.
> 
> This series removes those producer-side acquisitions entirely.

Thanks.  We're still awaiting review of [2/2].  I'll get this under
test in order to parallelize things.

> Measurement is a 30 s `perf lock record -a` window
> over otherwise-idle hardware.
> 
> Workload rates are identical on both kernels (the bench drives the
> same memory pressure):
> 
>                           baseline    patched      delta
>   pgscan_direct  / s      172,662     171,817      ~0%
>   pgsteal_direct / s       67,162      66,306      ~0%
>   workingset_refault_anon / s
>                            40,696      39,830      ~0%
> 
> perf lock contention (total wait per 30 s window):
> 
>   Lock Name                Before      After     % change
>   shrink_lruvec+0x770     722.84 ms    0         -100% (eliminated)
>         (= lru_note_cost_unlock_irq)
>   workingset_refault+0x167 385.26 ms   0         -100% (eliminated)
>         (= lru_note_cost_refault)
>   shrink_node+0x4ad       689.43 ms    26.95 ms  -96%
>   shrink_active_list      208.34 ms    15.97 ms  -92%
>   lru_add_drain_cpu+0x34    1.96 s    917.71 ms  -53%
> 
>   Total LRU lock wait      ~4.23 s     ~1.66 s   -61%

So it saves 2.5 seconds out of 30 seconds?