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

[Shakeel Butt]

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.
> 
> But tbf, I don't have a concrete usecase, and I wouldn't put up a patch to expose
> them to userspace if it werent for this patch itself.
> 
> I definitely dont want to create another hidden lruvec rstat infrastructure for this,
> it would be too much code churn. If the stats really shouldn't be exposed to userspace,
> would something like below be acceptable?
> 

Yes, the code seems reasonable to me.