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

[Richard Chang]

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()?