Re: [PATCH 1/1] mm/vmscan: prevent MGLRU reclaim from pinning address space

[Suren Baghdasaryan]

On Fri, Mar 27, 2026 at 12:53 PM Andrew Morton
<akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Fri, 27 Mar 2026 08:20:06 -0700 Suren Baghdasaryan <surenb@xxxxxxxxxx> wrote:
>
> > > Given you have cleared up my concerns, this LGTM, so:
> > >
> > > Reviewed-by: Lorenzo Stoakes (Oracle) <ljs@xxxxxxxxxx>
> >
> > Hi Andrew,
> > Any concerns about this patch or do you want someone maintaining MGLRU
> > to Ack it before pulling into your tree?
>
> That would of course be welcome.  But Suren+Lorenzo is more than
> enough for me.
>
> > The change is quite simple and I explain in my reply why it's safe,
> > Sashiko seems to like it and I extensively tested it on Android.
> > Please let me know if anything else is needed.
>
> I think that if the fix is valuable enough for Android to backport then
> we at least should have the Fixes: there to help others who are using
> MGLRU on older kernels.  (We don't have an "Improves:"!) And if it's a
> really big improvement then we could even pretend it's a bugfix and
> sneak it into -stable ;)
>
> But the changelog doesn't say much at all about how this change affects
> users.  Just "delays".  So can you please expand on this (numbers are
> always nice) and I can paste that into the changelog.

It affects the system in the sense that if the MM of the killed
process is being reclaimed by kswapd then reapers won't be able to
reap it. Even the process itself (which might have higher-priority
than kswapd) will not free its memory until kswapd drops the last
reference. IOW, we delay freeing the memory because kswapd is
reclaiming it. In Android the visible result for us is that
process_mrelease() (userspace reaper) skips MM in such cases and we
see process memory not released for an unusually long time (secs).

>
> Thanks.