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

[Shakeel Butt]

On Mon, Jul 27, 2026 at 09:57:05AM -0400, Johannes Weiner wrote:
> On Fri, Jul 24, 2026 at 02:32:52PM -0400, Johannes Weiner wrote:
> > On Fri, Jul 24, 2026 at 02:29:23PM +0100, Usama Arif wrote:
> > > 

[...]

> > > 
> > > > 
> > > > The patch looks good but I have one question. We already have concept of
> > > > pgrotated through /proc/vmstat which represents number of pages we have moved to
> > > > the tail of inactive LRU to make them next reclaim candidates. This patch is
> > > > exposing pgrotate_[anon|file] to userspace. Here these metrics represents either
> > > > the number of pages we scanned but didn't reclaim plus number of pages given one
> > > > more trip in the active LRU.
> > > > 
> > > > Older and newer pgrotate metrics kind of represent something different. It may
> > > > cause confusion. Now before suggesting to change the name, let me ask do we
> > > > really need to expose these to the userspace? How exactly users can use these
> > > > new metrics? I think you can use them here without exposing to userspace. So,
> > > > does it makes sense to delay userspace exposure later when we have a more solid
> > > > usecase for that unless you have it already.
> > > > 
> > > 
> > > I do think the userspace counters have diagnostic value. They can be another metric
> > > to show how much anon/file reclaim work is spent on pages that are not immediately
> > > reclaimed, including pages retained on actie LRU. It could help explain if there
> > > is elevated reclaim CPU usage.
> > 
> > Hm, this is an interesting discussion.
> > 
> > The existing PGROTATED is kind of useless. When it's bumped:
> > 
> > - truncation fails and moves folios to the LRU tail for faster reclaim
> > - writeback ends on folio that was tried to reclaim, moves to LRU tail for fast retry

Yes PGROTATED only tells number of pages moved to LRU tail and nothing about the
why. I can see that from user's perspective the why part is more important.

> > 
> > Ok, who needs to know this? The new counters you're adding, on the
> > other hand, they capture the information you frequently need for
> > understanding reclaim behavior.
> > 
> > That said, looking closer at this one more time, you can already
> > (almost) derive them fully from existing counters:
> > 
> > drotated = (dPGSCAN_ANON - dPGSTEAL_ANON) + dPGDEACTIVATE_ANON
> 
> Talking with Usama offlist, there are two problems with this:
> 
> - PGDEACTIVATE is obviously wrong. We want the the pages we don't
>   deactivate (hot file executables)
> 
> - PGSCAN includes things that didn't work out due to caller
>   restrictions (reclaim_idx) and race conditions (tryget, !lru) that
>   shouldn't contribute to the balance.
> 
> So let's go with PGROTATE as Usama proposed.
> 
> But I'm against hiding them from the vmstats.
> 
> I'd rather remove or rename the existing one if we're worried about
> confusion. We've historically applied a much lower bar to vmstat
> stability. It's geared towards understanding detailed MM behavior
> behavior, which undergoes constant changes.

Let's keep the deprecation part orthogonal to this series. No objection from me
if these new metrics help in understanding the MM reclaim behavior. The only
request I have is to introduce these metrics as a separate independent patch.
First introduce the metrics with the detail on how they can be useful and then
later use them for the internal balancing algorithm.