Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Chang <richardycc@google.com>
To: 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>,
	Michal Hocko <mhocko@kernel.org>,
	 Lorenzo Stoakes <ljs@kernel.org>
Cc: 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,
	Richard Chang <richardycc@google.com>
Subject: [PATCH v2] mm: vmscan: abort proactive reclaim early when freezing for suspend
Date: Thu,  9 Jul 2026 07:22:31 +0000	[thread overview]
Message-ID: <20260709072231.3163082-1-richardycc@google.com> (raw)
In-Reply-To: <ak5-qwmpXrYi5md6@linux.dev>

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 the tasks
by sending signals. 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 reclaim loop with a large target for a single syscall
invocation. In contrast, reactive reclaim (global/memcg) has small
targets (SWAP_CLUSTER_MAX, typically 32 pages), allowing to yield or
check signals between attempts quickly.

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, ensuring the task can enter
the refrigerator and allow suspend to proceed.

The check is limited to proactive reclaim (sc->proactive) to avoid
affecting reactive reclaim paths, and wrapped in unlikely() as it
is a slow path.

Signed-off-by: Richard Chang <richardycc@google.com>
---
v2: Update the commit message

 mm/vmscan.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 35c3bb15ae96..fb472e924fc7 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;
 
-- 
2.55.0.795.g602f6c329a-goog



  reply	other threads:[~2026-07-09  7:23 UTC|newest]

Thread overview: 19+ 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               ` Richard Chang [this message]
2026-07-09 12:06                 ` [PATCH v2] mm: vmscan: abort proactive reclaim early when freezing for suspend Michal Hocko
2026-07-10  3:29                   ` Richard Chang
2026-07-10  6:27                     ` Michal Hocko

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=20260709072231.3163082-1-richardycc@google.com \
    --to=richardycc@google.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=mhocko@kernel.org \
    --cc=minchan@kernel.org \
    --cc=qi.zheng@linux.dev \
    --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