From: Peter Zijlstra <peterz@infradead.org>
To: Julian Sun <sunjunchao@bytedance.com>
Cc: cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org, lance.yang@linux.dev,
mhiramat@kernel.org, yangyicong@hisilicon.com, will@kernel.org,
dianders@chromium.org, mingo@kernel.org, lihuafei1@huawei.com,
hannes@cmpxchg.org, mhocko@kernel.org, roman.gushchin@linux.dev,
shakeel.butt@linux.dev, muchun.song@linux.dev, tj@kernel.org
Subject: Re: [External] Re: [PATCH v2 2/2] memcg: Don't trigger hung task warnings when memcg is releasing resources.
Date: Wed, 24 Sep 2025 10:28:23 +0200 [thread overview]
Message-ID: <20250924082823.GV3245006@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <37fd969e-3799-48d0-a8e0-1937e5a4ae38@bytedance.com>
On Wed, Sep 24, 2025 at 03:50:41PM +0800, Julian Sun wrote:
> On 9/24/25 2:32 PM, Peter Zijlstra wrote:
> > On Wed, Sep 24, 2025 at 11:41:00AM +0800, Julian Sun wrote:
> > > Hung task warning in mem_cgroup_css_free() is undesirable and
> > > unnecessary since the behavior of waiting for a long time is
> > > expected.
> > >
> > > Use touch_hung_task_detector() to eliminate the possible
> > > hung task warning.
> > >
> > > Signed-off-by: Julian Sun <sunjunchao@bytedance.com>
> >
> > Still hate this. It is not tied to progress. If progress really stalls,
> > no warning will be given.
>
> Hi, peter
>
> Thanks for your review and comments.
>
> I did take a look at your solution provided yesterday, and get your point.
> However AFAICS it can't resolve the unexpected warnings here. Because it
> only works after we reach the finish_writeback_work(), and the key point
> here is, it *already* takes a long time before we reach
> finish_writeback_work(), and there is true progress before finish the
> writeback work that hung task detector still can not know.
But wb_split_bdi_pages() should already split things into smaller chunks
if there is low bandwidth, right? And we call finish_writeback_work()
for each chunk.
If a chunk is still taking too long, surely the solution is to use
smaller chunks?
> If we want to make the hung task detector to known the progress of writeback
> work, we need to add some code within do_writepages(): after each finish of
> a_ops->writepages(), we need to make detector to known there's progress.
> Something like this:
>
> diff --git a/mm/page-writeback.c b/mm/page-writeback.c
> index 3e248d1c3969..49572a83c47b 100644
> --- a/mm/page-writeback.c
> +++ b/mm/page-writeback.c
> @@ -2635,6 +2635,10 @@ int do_writepages(struct address_space *mapping,
> struct writeback_control *wbc)
> else
> /* deal with chardevs and other special files */
> ret = 0;
> + /* Make hung task detector to known there's progress. */
> + if (force_wake)
> + wake_up_all(waitq);
> +
> if (ret != -ENOMEM || wbc->sync_mode != WB_SYNC_ALL)
> break;
>
> which has a big impact on current code - I don't want to introduce this.
You sure? It looks to me like the next level down is wb_writeback() and
writeback_sb_inodes(), and those already have time based breaks in and
still have access to wb_writeback_work::done, while do_writepages() no
longer has that context.
> Yes, the behavior in this patch does have the possibility to paper cover the
> real warnings, and what I want to argue is that the essence of this patch is
> the same as the current touch_nmi_watchdog() and touch_softlockup_watchdog()
> - these functions are used only in specific scenarios we known and only
> affect a single event. And there seems no report that
> touch_nmi/softlockup_watchdog() will paper cover the real warnings (do we?).
>
> Correct me if there's anything I'm missing or misunderstanding.
The thing with touch_nmi_watchdog() is that you need to keep doing it.
The moment you stop calling touch_nmi_watchdog(), you will cause it to
fire.
That is very much in line with the thing I proposed, and rather unlike
your proposal that blanket kill reporting for the task, irrespective of
how long it sits there waiting.
next prev parent reply other threads:[~2025-09-24 8:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-24 3:40 [PATCH v2 0/2] Suppress undesirable hung task warnings Julian Sun
2025-09-24 3:40 ` [PATCH v2 1/2] hung_task: Introduce touch_hung_task_detector() Julian Sun
2025-09-25 13:33 ` Masami Hiramatsu
2025-09-24 3:41 ` [PATCH v2 2/2] memcg: Don't trigger hung task warnings when memcg is releasing resources Julian Sun
2025-09-24 6:32 ` Peter Zijlstra
2025-09-24 7:50 ` [External] " Julian Sun
2025-09-24 8:28 ` Peter Zijlstra [this message]
2025-09-24 10:36 ` Julian Sun
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=20250924082823.GV3245006@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=hannes@cmpxchg.org \
--cc=lance.yang@linux.dev \
--cc=lihuafei1@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=mhocko@kernel.org \
--cc=mingo@kernel.org \
--cc=muchun.song@linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=sunjunchao@bytedance.com \
--cc=tj@kernel.org \
--cc=will@kernel.org \
--cc=yangyicong@hisilicon.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
all inboxes | Powered by JetHome®