Re: [PATCH] mm/vmscan: reclaim every zone in per-node proactive reclaim

[Balbir Singh <balbirs@nvidia.com>]

On Mon, Oct 19, 2026 at 11:04:12PM -0400, Gregory Price wrote:
> On Tue, Oct 20, 2026 at 12:49:37PM +1100, Balbir Singh wrote:
> > > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > > index e82ba737c028d..90f7a7bf4e426 100644
> > > --- a/mm/vmscan.c
> > > +++ b/mm/vmscan.c
> > > @@ -8180,7 +8180,7 @@ int user_proactive_reclaim(char *buf,
> > >  		} else {
> > >  			struct scan_control sc = {
> > >  				.gfp_mask = current_gfp_context(gfp_mask),
> > > -				.reclaim_idx = gfp_zone(gfp_mask),
> > > +				.reclaim_idx = MAX_NR_ZONES - 1,
> > >  				.proactive_swappiness = swappiness == -1 ? NULL : &swappiness,
> > >  				.priority = DEF_PRIORITY,
> > >  				.may_writepage = 1,
> > 
> > 
> > I just noticed some other issues with this code, in terms of honouring
> > zone_reclaim_node (not related to this patch). I'll send out fixes, for
> > this patch.
> 
> I'm shocked, I tell you, shocked!
> 
> These are all things I accidentally ran into by just uh... using the
> interface.  I'm absolutely positive these interfaces are full of bugs.
>

:)

I was looking at making may_writepage and may_unmap align with the
constraints of node zone reclaim, .may_writepage = !!(node_reclaim_mode & RECLAIM_WRITE),
and .may_unmap = !!(node_reclaim_mode & RECLAIM_UNMAP), which may
violate the contract for proactive reclaim. Proactive reclaim itself
tries to be compatible with cgroups reclaim interface, so it sets these
values to 1. I still feel it is a violation of default node reclaim
parameters, but not sure if it needs to be fixed up.

Balbir