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: 25+ 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
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.