Re: [PATCH v4] mm: vmscan: abort proactive reclaim early when freezing for suspend

[Andrew Morton]

On Mon, 20 Jul 2026 20:04:30 +0800 Richard Chang <richardycc@xxxxxxxxxx> wrote:

> Hi Andrew,
> Thanks for pointing that out.
> 
> On Mon, Jul 20, 2026 at 1:23 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > So 287d5fedb377 led to suspend failures on MGLRU-using kernels.
> >
> > That's a regression which justifies a Fixes: and a cc:stable, don't
> > people agree?
> >
> > AI review asked a couple of serious-sounding questions:
> >         https://sashiko.dev/#/patchset/20260720044103.905191-1-richardycc@xxxxxxxxxx
> >
> 
> Hi Michal and Oleg,
> 
> The -ERESTARTSYS concern raised during the AI review seems reasonable:
> 1. Over-Reclaim: If a task has already reclaimed 900MB of a 1GB
> request before being interrupted by a suspend, an -ERESTARTSYS would
> attempt to reclaim another 1GB when resuming, resulting in up to 1.9GB
> of over-reclaim.
> 2. Incompatibility Node-Reclaim: Since reclaim_store() unconditionally
> converts any non-zero return value from user_proactive_reclaim() into
> -EAGAIN, it will not restart the syscall for node reclaim.
> Given these constraints, do you think we should keep -EINTR in
> user_proactive_reclaim()?

It's been a long time.  Did the above two issues receive consideration?

Thanks.