From: Lance Yang <lance.yang@linux.dev>
To: Julian Sun <sunjunchao@bytedance.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: mhiramat@kernel.org, viro@zeniv.linux.org.uk, brauner@kernel.org,
jack@suse.cz, mingo@redhat.com, peterz@infradead.org,
juri.lelli@redhat.com, vincent.guittot@linaro.org,
dietmar.eggemann@arm.com, rostedt@goodmis.org,
bsegall@google.com, mgorman@suse.de, vschneid@redhat.com,
agruenba@redhat.com, hannes@cmpxchg.org, mhocko@kernel.org,
roman.gushchin@linux.dev, shakeel.butt@linux.dev,
muchun.song@linux.dev, linux-kernel@vger.kernel.org,
cgroups@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 0/3] Suppress undesirable hung task warnings.
Date: Tue, 23 Sep 2025 10:30:18 +0800 [thread overview]
Message-ID: <9665ff9f-3e1d-4c39-8c8f-b9e12fb4d5f4@linux.dev> (raw)
In-Reply-To: <20250922145754.31890092257495f70db3909d@linux-foundation.org>
On 2025/9/23 05:57, Andrew Morton wrote:
> On Mon, 22 Sep 2025 19:38:21 +0800 Lance Yang <lance.yang@linux.dev> wrote:
>
>> On 2025/9/22 17:41, Julian Sun wrote:
>>> As suggested by Andrew Morton in [1], we need a general mechanism
>>> that allows the hung task detector to ignore unnecessary hung
>>
>> Yep, I understand the goal is to suppress what can be a benign hung task
>> warning during memcg teardown.
>>
>>> tasks. This patch set implements this functionality.
>>>
>>> Patch 1 introduces a PF_DONT_HUNG flag. The hung task detector will
>>> ignores all tasks that have the PF_DONT_HUNG flag set.
>>
>> However, I'm concerned that the PF_DONT_HUNG flag is a bit too powerful
>> and might mask real, underlying hangs.
>
> I think that's OK if the calling task is discriminating about it. Just
> set PF_DONT_HUNG (unpleasing name!) around those bits of code where
> it's needed, clear it otherwise.
Makes sense to me :)
>
> Julian, did you take a look at what a touch_hung_task_detector() would
> involve? It's a bit of an interface inconsistency - our various other
> timeout detectors (softlockup, NMI, rcu) each have a touch_ function.
On second thought, I agree that a touch_hung_task_detector() would be a
much better approach for interface consistency.
We could implement touch_hung_task_detector() to grant the task temporary
immunity from hung task checks for as long as it remains uninterruptible.
Once the task becomes runnable again, the immunity is automatically revoked.
Something like this:
---
diff --git a/include/linux/hung_task.h b/include/linux/hung_task.h
index c4403eeb7144..fac92039dce0 100644
--- a/include/linux/hung_task.h
+++ b/include/linux/hung_task.h
@@ -98,4 +98,9 @@ static inline void *hung_task_blocker_to_lock(unsigned
long blocker)
}
#endif
+void touch_hung_task_detector(struct task_struct *t)
+{
+ t->last_switch_count = ULONG_MAX;
+}
+
#endif /* __LINUX_HUNG_TASK_H */
diff --git a/kernel/hung_task.c b/kernel/hung_task.c
index 8708a1205f82..094a277b3b39 100644
--- a/kernel/hung_task.c
+++ b/kernel/hung_task.c
@@ -203,6 +203,9 @@ static void check_hung_task(struct task_struct *t,
unsigned long timeout)
if (unlikely(!switch_count))
return;
+ if (t->last_switch_count == ULONG_MAX)
+ return;
+
if (switch_count != t->last_switch_count) {
t->last_switch_count = switch_count;
t->last_switch_time = jiffies;
@@ -317,6 +320,9 @@ static void
check_hung_uninterruptible_tasks(unsigned long timeout)
!(state & TASK_WAKEKILL) &&
!(state & TASK_NOLOAD))
check_hung_task(t, timeout);
+ else if (t->last_switch_count == ULONG_MAX)
+ t->last_switch_count = t->nvcsw + t->nivcsw;
+
}
unlock:
rcu_read_unlock();
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 8dc470aa6c3c..3d5f36455b74 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3910,8 +3910,10 @@ static void mem_cgroup_css_free(struct
cgroup_subsys_state *css)
int __maybe_unused i;
#ifdef CONFIG_CGROUP_WRITEBACK
- for (i = 0; i < MEMCG_CGWB_FRN_CNT; i++)
+ for (i = 0; i < MEMCG_CGWB_FRN_CNT; i++) {
+ touch_hung_task_detector(current);
wb_wait_for_completion(&memcg->cgwb_frn[i].done);
+ }
#endif
if (cgroup_subsys_on_dfl(memory_cgrp_subsys) && !cgroup_memory_nosocket)
static_branch_dec(&memcg_sockets_enabled_key);
---
Using ULONG_MAX as a marker to grant this immunity. As long as the task
remains in state D, check_hung_task() sees the marker and bails out.
next prev parent reply other threads:[~2025-09-23 2:30 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-22 9:41 [PATCH 0/3] Suppress undesirable hung task warnings Julian Sun
2025-09-22 9:41 ` [PATCH 1/3] sched: Introduce a new flag PF_DONT_HUNG Julian Sun
2025-09-22 9:41 ` [PATCH 2/3] writeback: Introduce wb_wait_for_completion_no_hung() Julian Sun
2025-09-22 9:41 ` [PATCH 3/3] memcg: Don't trigger hung task warnings when memcg is releasing resources Julian Sun
2025-09-22 11:38 ` [PATCH 0/3] Suppress undesirable hung task warnings Lance Yang
2025-09-22 12:40 ` Julian Sun
2025-09-22 13:12 ` Lance Yang
2025-09-22 21:57 ` Andrew Morton
2025-09-23 2:30 ` Lance Yang [this message]
2025-09-23 2:45 ` [External] " Julian Sun
2025-09-23 3:18 ` Lance Yang
2025-09-22 13:07 ` Michal Hocko
2025-09-22 14:24 ` [External] " Julian Sun
2025-09-22 13:27 ` Peter Zijlstra
2025-09-22 14:29 ` [External] " Julian Sun
2025-09-22 15:27 ` Jan Kara
2025-09-22 18:08 ` Christoph Hellwig
2025-09-22 21:50 ` Andrew Morton
2025-09-23 7:16 ` Peter Zijlstra
2025-09-23 12:44 ` Masami Hiramatsu
2025-09-24 10:34 ` Jan Kara
2025-09-25 15:07 ` [External] " Julian Sun
2025-09-25 16:30 ` Jan Kara
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=9665ff9f-3e1d-4c39-8c8f-b9e12fb4d5f4@linux.dev \
--to=lance.yang@linux.dev \
--cc=agruenba@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=bsegall@google.com \
--cc=cgroups@vger.kernel.org \
--cc=dietmar.eggemann@arm.com \
--cc=hannes@cmpxchg.org \
--cc=jack@suse.cz \
--cc=juri.lelli@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mhiramat@kernel.org \
--cc=mhocko@kernel.org \
--cc=mingo@redhat.com \
--cc=muchun.song@linux.dev \
--cc=peterz@infradead.org \
--cc=roman.gushchin@linux.dev \
--cc=rostedt@goodmis.org \
--cc=shakeel.butt@linux.dev \
--cc=sunjunchao@bytedance.com \
--cc=vincent.guittot@linaro.org \
--cc=viro@zeniv.linux.org.uk \
--cc=vschneid@redhat.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.