The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Richard Chang <richardycc@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Kairui Song <kasong@tencent.com>, Qi Zheng <qi.zheng@linux.dev>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	Barry Song <baohua@kernel.org>,
	Axel Rasmussen <axelrasmussen@google.com>,
	Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	David Hildenbrand <david@kernel.org>,
	Lorenzo Stoakes <ljs@kernel.org>, Oleg Nesterov <oleg@redhat.com>,
	Suren Baghdasaryan <surenb@google.com>,
	"T . J . Mercier" <tjmercier@google.com>,
	Martin Liu <liumartin@google.com>,
	Minchan Kim <minchan@kernel.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] mm: vmscan: abort proactive reclaim early when freezing for suspend
Date: Tue, 21 Jul 2026 14:30:37 +0200	[thread overview]
Message-ID: <al9mbf00nCx9gWS2@tiehlicka> (raw)
In-Reply-To: <20260720044103.905191-1-richardycc@google.com>

On Mon 20-07-26 04:41:03, Richard Chang wrote:
> Proactive reclaim (triggered via memory.reclaim or node sysfs) checks
> for pending signals in its outer loop in user_proactive_reclaim().
> However, the inner reclaim loops—specifically scanning cgroups in
> shrink_many() and evicting/aging folios in try_to_shrink_lruvec()—can
> run for a long time before returning to the outer loop, especially on
> systems with many cgroups or large memory sizes.
> 
> During system suspend, the PM freezer attempts to freeze all tasks by
> sending fake signals (setting TIF_SIGPENDING). Because the inner loops
> do not check for pending signals, the proactive reclaim task can remain
> stuck in kernel space for seconds, failing to enter the refrigerator in
> a timely manner. This leads to suspend failures due to freeze timeouts,
> a behavior observed on Android devices.
> 
> This latency issue is specific to proactive reclaim because of its
> large, user-defined reclaim targets (could be gigabytes). Since commit
> 287d5fedb377 ("mm: memcg: use larger batches for proactive reclaim"),
> proactive reclaim uses larger decaying batch sizes (starting at 1/4 of
> the remaining target) to maintain throughput. This keeps the task in
> the inner reclaim loop for extended periods. In contrast, reactive
> reclaim (global/memcg) uses small targets (SWAP_CLUSTER_MAX, typically
> 32 pages), allowing it to return to the outer loop and check signals
> frequently.
> 
> To fix this, add a signal_pending() check to should_abort_scan() for
> proactive reclaim paths. Since should_abort_scan() is called within
> the inner scanning and eviction loops, this allows proactive reclaim to
> abort early and return to the outer loop in user_proactive_reclaim().
> 
> Additionally, return -ERESTARTSYS instead of -EINTR in
> user_proactive_reclaim(). When interrupted by system suspend, returning
> -ERESTARTSYS allows the task to enter the refrigerator and automatically
> restart the syscall upon resume, making the freezer transparent to
> userspace. For real signals, the signal layer will either restart the
> syscall (if SA_RESTART is set) or return -EINTR to userspace.
> 
> This fix specifically targets Multi-Gen LRU (MGLRU). Classic LRU's scan
> targets per iteration are strictly bounded by get_scan_count(), which
> ensures it returns to the outer loop more frequently.
> 
> The check in should_abort_scan() is limited to proactive reclaim
> (sc->proactive) to avoid inadvertently affecting reactive reclaim paths,
> and is wrapped in unlikely() as it is a slow path.
> 
> Suggested-by: Michal Hocko <mhocko@suse.com>
> Suggested-by: Oleg Nesterov <oleg@redhat.com>
> Signed-off-by: Richard Chang <richardycc@google.com>

Acked-by: Michal Hocko <mhocko@suse.com>
Thanks

> ---
> v2: Update the commit message
> v3: Return -ERESTARTSYS instead of -EINTR in user_proactive_reclaim
> v4: Clarify -ERESTARTSYS vs SA_RESTART behavior
> 
>  mm/vmscan.c | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 35c3bb15ae96..5aa4becacb7f 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -4929,6 +4929,9 @@ static bool should_abort_scan(struct lruvec *lruvec, struct scan_control *sc)
>  	int i;
>  	enum zone_watermarks mark;
>  
> +	if (unlikely(sc->proactive && signal_pending(current)))
> +		return true;
> +
>  	if (sc->nr_reclaimed >= max(sc->nr_to_reclaim, compact_gap(sc->order)))
>  		return true;
>  
> @@ -7909,8 +7912,15 @@ int user_proactive_reclaim(char *buf,
>  		unsigned long batch_size = (nr_to_reclaim - nr_reclaimed) / 4;
>  		unsigned long reclaimed;
>  
> +		/*
> +		 * Return -ERESTARTSYS to allow the freezer to interrupt the
> +		 * task. The syscall will be transparently restarted upon
> +		 * resume. For real signals, it either restarts the syscall
> +		 * (if SA_RESTART is set) or is converted to -EINTR by the
> +		 * signal layer.
> +		 */
>  		if (signal_pending(current))
> -			return -EINTR;
> +			return -ERESTARTSYS;
>  
>  		/*
>  		 * This is the final attempt, drain percpu lru caches in the
> -- 
> 2.55.0.229.g6434b31f56-goog

-- 
Michal Hocko
SUSE Labs

      parent reply	other threads:[~2026-07-21 12:30 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-06  8:12 [PATCH] mm: vmscan: abort proactive reclaim early when freezing Richard Chang
2026-07-06 12:54 ` Barry Song
2026-07-07  8:00   ` Richard Chang
2026-07-06 23:38 ` Andrew Morton
2026-07-07 10:13   ` Richard Chang
2026-07-07  2:20 ` Yosry Ahmed
2026-07-07  8:04   ` Richard Chang
2026-07-07 18:28     ` Yosry Ahmed
2026-07-07 19:48 ` Shakeel Butt
2026-07-08  4:14   ` Richard Chang
2026-07-08  4:54     ` Shakeel Butt
2026-07-08  7:24       ` Richard Chang
2026-07-08 15:47         ` Shakeel Butt
2026-07-08 16:03           ` T.J. Mercier
2026-07-08 16:51             ` Shakeel Butt
2026-07-09  7:22               ` [PATCH v2] mm: vmscan: abort proactive reclaim early when freezing for suspend Richard Chang
2026-07-09 12:06                 ` Michal Hocko
2026-07-10  3:29                   ` Richard Chang
2026-07-10  6:27                     ` Michal Hocko
2026-07-14  9:00                       ` Richard Chang
2026-07-14 12:23                         ` Michal Hocko
2026-07-14 12:40                           ` Michal Hocko
2026-07-15  7:56                             ` Richard Chang
2026-07-15  8:49                               ` Michal Hocko
2026-07-15 17:47                                 ` Oleg Nesterov
2026-07-15 19:58                                   ` Michal Hocko
2026-07-17  9:14                                     ` Richard Chang
2026-07-17 18:12                                       ` [PATCH v3] " Richard Chang
2026-07-17 18:47                                         ` Oleg Nesterov
2026-07-20  4:37                                           ` Richard Chang
2026-07-20  4:41                                             ` [PATCH v4] " Richard Chang
2026-07-20  5:23                                               ` Andrew Morton
2026-07-20 12:04                                                 ` Richard Chang
2026-07-21 12:32                                                 ` Michal Hocko
2026-07-21 12:30                                               ` Michal Hocko [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=al9mbf00nCx9gWS2@tiehlicka \
    --to=mhocko@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=baohua@kernel.org \
    --cc=david@kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=kasong@tencent.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liumartin@google.com \
    --cc=ljs@kernel.org \
    --cc=minchan@kernel.org \
    --cc=oleg@redhat.com \
    --cc=qi.zheng@linux.dev \
    --cc=richardycc@google.com \
    --cc=shakeel.butt@linux.dev \
    --cc=surenb@google.com \
    --cc=tjmercier@google.com \
    --cc=weixugc@google.com \
    --cc=yuanchu@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox