From: Andrew Morton <akpm@linux-foundation.org>
To: Julian Sun <sunjunchao@bytedance.com>
Cc: cgroups@vger.kernel.org, linux-mm@kvack.org, jack@suse.cz,
tj@kernel.org, muchun.song@linux.dev, venkat88@linux.ibm.com,
hannes@cmpxchg.org, mhocko@kernel.org, roman.gushchin@linux.dev,
shakeel.butt@linux.dev, Lance Yang <lance.yang@linux.dev>,
Masami Hiramatsu <mhiramat@kernel.org>
Subject: Re: [External] Re: [PATCH v6] memcg: Don't wait writeback completion when release memcg.
Date: Wed, 17 Sep 2025 21:32:03 -0700 [thread overview]
Message-ID: <20250917213203.4608d54da45a5b8bc80c2004@linux-foundation.org> (raw)
In-Reply-To: <CAHSKhtdPGuMW0jRRgARGt+ZdnC02v9O11=ofsgRmnZny3c5aaw@mail.gmail.com>
On Thu, 18 Sep 2025 12:22:35 +0800 Julian Sun <sunjunchao@bytedance.com> wrote:
> > Seems the intent here is mainly to prevent the warning. If that
> > warning wasn't coming out, would we bother making these changes? If
> > no, just kill the warning.
>
> Got it. Seems like there's no more impact other than the pesky warning.
> BTW, I'm also seeing many hung task warnings when the mount/umount
> syscall is waiting for the s_umount semaphore—while s_umount is held
> by the writeback code path. I think the hung task is also undesirable,
> right? Since AFAICS there's also no more impact instead of the pesky
> warnings.
Sure. Writeback is famous for potentially taking vast amounts of time
and that's perfectly reasonable and expected - lots of dirty data takes
lots of time to write out. There is no misbehavior in this and warning
the operator about it is just silly. If there is no action either they
or we can take to prevent the warning then just squash the warning.
prev parent reply other threads:[~2025-09-18 4:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-17 21:29 Julian Sun
2025-09-17 21:50 ` Tejun Heo
2025-09-18 2:27 ` [External] " Julian Sun
2025-09-17 22:21 ` Andrew Morton
2025-09-18 2:43 ` Lance Yang
2025-09-18 3:03 ` [External] " Julian Sun
2025-09-18 3:26 ` Andrew Morton
2025-09-18 4:22 ` Julian Sun
2025-09-18 4:32 ` Andrew Morton [this message]
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=20250917213203.4608d54da45a5b8bc80c2004@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=jack@suse.cz \
--cc=lance.yang@linux.dev \
--cc=linux-mm@kvack.org \
--cc=mhiramat@kernel.org \
--cc=mhocko@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=venkat88@linux.ibm.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