From: Michal Hocko <mhocko@suse.com>
To: Richard Chang <richardycc@google.com>, Oleg Nesterov <oleg@redhat.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>,
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 v2] mm: vmscan: abort proactive reclaim early when freezing for suspend
Date: Wed, 15 Jul 2026 10:49:35 +0200 [thread overview]
Message-ID: <aldJnz0u1YyoCyGr@tiehlicka> (raw)
In-Reply-To: <CALC_0q_9DamACOEyXeevWvq-6D9dQZ6NNt=iBN7gkOQRM9xqfw@mail.gmail.com>
[Add Oleg]
On Wed 15-07-26 15:56:49, Richard Chang wrote:
> Hi Michal,
> Thanks for the patch.
> Yes, inserting try_to_freeze() at that point carries low risk.
> However, there are still a few issues:
>
> 1. As I understand it, fatal_signal_pending() only checks for SIGKILL
> (via sigismember(..., SIGKILL)).
> It does not return true for SIGINT (Ctrl+C), even if the signal is
> unhandled and will eventually terminate the task.
> If we switch to fatal_signal_pending, a large proactive reclaim task
> will continue reclaiming until the loop finishes.
OK, I see you concern now. The code is a bit confusing in this respect.
You are right that fatal_signal_pending returns true only if SIGKILL is
flagged. You need to have a look at the signal delivery path though. If
there is a terminating signal sent and there is a default handler
(sig_fatal) then complete_signal will add SIGKILL to kill the whole
process group.
> 2. try_to_freeze() does not clear the TIF_SIGPENDING flag. When the
> task resumes and continues the user_proactive_reclaim() loop, the next
> iteration of the inner loop will immediately abort.
You are right. I forgot that try_to_freeze is not really aimed to be
used for user processes. Rather than trying to enforce explicit
try_to_freeze and dealing with pending signals I believe the right
approach would be to instead simply do the following.
Oleg you haven't been CCed from the top of the thread but TL;DR is that
we need to freeze a user task performing pro-active memory reclaim that
might take long. Currently we are calling signal_pending to bail out
but that leaks EINTR which is bad as freezing task has a side effect of
terminating it.
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 35c3bb15ae96..336af76d2a28 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -7909,8 +7909,13 @@ int user_proactive_reclaim(char *buf,
unsigned long batch_size = (nr_to_reclaim - nr_reclaimed) / 4;
unsigned long reclaimed;
+ /*
+ * Make sure that we enter freezer without delaying much and
+ * leaking EINTR when that happens but also take care of
+ * fatal signals to terminate.
+ */
if (signal_pending(current))
- return -EINTR;
+ return -ERESTARTSYS;
/*
* This is the final attempt, drain percpu lru caches in the
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2026-07-15 8:49 UTC|newest]
Thread overview: 26+ 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 [this message]
2026-07-15 17:47 ` Oleg Nesterov
2026-07-15 19:58 ` 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=aldJnz0u1YyoCyGr@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