linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Julian Sun <sunjunchao@bytedance.com>,
	cgroups@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk,
	brauner@kernel.org, jack@suse.cz, mingo@redhat.com,
	juri.lelli@redhat.com, vincent.guittot@linaro.org,
	dietmar.eggemann@arm.com, rostedt@goodmis.org,
	bsegall@google.com, mgorman@suse.de, vschneid@redhat.com,
	lance.yang@linux.dev, mhiramat@kernel.org, agruenba@redhat.com,
	hannes@cmpxchg.org, mhocko@kernel.org, roman.gushchin@linux.dev,
	shakeel.butt@linux.dev, muchun.song@linux.dev
Subject: Re: [PATCH 0/3] Suppress undesirable hung task warnings.
Date: Mon, 22 Sep 2025 14:50:45 -0700	[thread overview]
Message-ID: <20250922145045.afc6593b4e91c55d8edefabb@linux-foundation.org> (raw)
In-Reply-To: <aNGQoPFTH2_xrd9L@infradead.org>

On Mon, 22 Sep 2025 11:08:32 -0700 Christoph Hellwig <hch@infradead.org> wrote:

> On Mon, Sep 22, 2025 at 03:27:18PM +0200, Peter Zijlstra wrote:
> > > Julian Sun (3):
> > >   sched: Introduce a new flag PF_DONT_HUNG.
> > >   writeback: Introduce wb_wait_for_completion_no_hung().
> > >   memcg: Don't trigger hung task when memcg is releasing.
> > 
> > This is all quite terrible. I'm not at all sure why a task that is
> > genuinely not making progress and isn't killable should not be reported.
> 
> The hung device detector is way to aggressive for very slow I/O.
> See blk_wait_io, which has been around for a long time to work
> around just that.  Given that this series targets writeback I suspect
> it is about an overloaded device as well.

Yup, it's writeback - the bug report is in
https://lkml.kernel.org/r/20250917212959.355656-1-sunjunchao@bytedance.com

Memory is big and storage is slow, there's nothing wrong if a task
which is designed to wait for writeback waits for a long time.

Of course, there's something wrong if some other task which isn't
designed to wait for writeback gets stuck waiting for the task which
*is* designed to wait for writeback, but we'll still warn about that.


Regarding an implementation, I'm wondering if we can put a flag in
`struct completion' telling the hung task detector that this one is
expected to wait for long periods sometimes.  Probably messy and it
only works for completions (not semaphores, mutexes, etc).  Just
putting it out there ;)


  reply	other threads:[~2025-09-22 21:50 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
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 [this message]
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=20250922145045.afc6593b4e91c55d8edefabb@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=agruenba@redhat.com \
    --cc=brauner@kernel.org \
    --cc=bsegall@google.com \
    --cc=cgroups@vger.kernel.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=hannes@cmpxchg.org \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=juri.lelli@redhat.com \
    --cc=lance.yang@linux.dev \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).