From: Giorgi Tchankvetadze <giorgitchankvetadze1997@gmail.com>
To: Julian Sun <sunjunchao@bytedance.com>
Cc: linux-fsdevel@vger.kernel.org, cgroups@vger.kernel.org,
linux-mm@kvack.org, viro@zeniv.linux.org.uk, brauner@kernel.org,
jack@suse.cz, hannes@cmpxchg.org, mhocko@kernel.org,
roman.gushchin@linux.dev, shakeel.butt@linux.dev,
muchun.song@linux.dev, axboe@kernel.dk, tj@kernel.org
Subject: Re: [External] Re: [PATCH 0/3] memcg, writeback: Don't wait writeback completion
Date: Fri, 22 Aug 2025 13:29:18 +0400 [thread overview]
Message-ID: <e5ef25e7-e4bd-40d4-9f0a-f1d4c1c8acbe@gmail.com> (raw)
In-Reply-To: <CAHSKhtch+eT2ehQ5weRGEJwTj1sw0vo0_4Tu=bfBuSsHXGm3ZQ@mail.gmail.com>
`memory.stat:writeback` already gives you the exact real-time count of
pages still waiting to finish write-back for that cgroup, and it is
updated atomically in the hot path (`set_page_writeback()` /
`end_page_writeback()`). Reading it is just an `atomic_long_read()` (or
per-cpu equivalent), so the extra CPU cost of exposing it is essentially
zero. I was thinking that extra additional info would help us
Thanks,
Giorgi
On 8/21/2025 6:37 AM, Julian Sun wrote:
> Hi, thanks for your review.
>
> On Wed, Aug 20, 2025 at 8:17 PM Giorgi Tchankvetadze
> <giorgitchankvetadze1997@gmail.com> wrote:
>>
>> Could we add wb_pending_pages to memory.events?
>> Very cheap and useful.
>> A single atomic counter is already kept internally; exposing it is one
>> line in memcontrol.c plus one line in the ABI doc.
>
> Not sure what do you mean by wb_pending_pages? Another counter besides
> existing MEMCG_LOW MEMCG_HIGH MEMCG_MAX, etc.? And AFAIK there's no
> pending pages in this patch set. Could you give more details?
>
> Thanks,
>>
>>
>> On 8/20/2025 3:19 PM, Julian Sun wrote:
>>> This patch series aims to eliminate task hangs in mem_cgroup_css_free()
>>> caused by calling wb_wait_for_completion().
>>> This is because there may be a large number of writeback tasks in the
>>> foreign memcg, involving millions of pages, and the situation is
>>> exacerbated by WBT rate limiting—potentially leading to task hangs
>>> lasting several hours.
>>>
>>> Patch 1 is preparatory work and involves no functional changes.
>>> Patch 2 implements the automatic release of wb_completion.
>>> Patch 3 removes wb_wait_for_completion() from mem_cgroup_css_free().
>>>
>>>
>>> Julian Sun (3):
>>> writeback: Rename wb_writeback_work->auto_free to free_work.
>>> writeback: Add wb_writeback_work->free_done
>>> memcg: Don't wait writeback completion when release memcg.
>>>
>>> fs/fs-writeback.c | 22 ++++++++++++++--------
>>> include/linux/backing-dev-defs.h | 6 ++++++
>>> include/linux/memcontrol.h | 2 +-
>>> mm/memcontrol.c | 29 ++++++++++++++++++++---------
>>> 4 files changed, 41 insertions(+), 18 deletions(-)
>>>
>>
prev parent reply other threads:[~2025-08-22 9:29 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-20 11:19 [PATCH 0/3] memcg, writeback: Don't wait writeback completion Julian Sun
2025-08-20 11:19 ` [PATCH 1/3] writeback: Rename wb_writeback_work->auto_free to free_work Julian Sun
2025-08-20 11:19 ` [PATCH] writeback: Add wb_writeback_work->free_done Julian Sun
2025-08-20 11:19 ` [PATCH] memcg: Don't wait writeback completion when release memcg Julian Sun
2025-08-20 20:58 ` Tejun Heo
2025-08-21 2:30 ` [External] " Julian Sun
2025-08-21 16:59 ` Tejun Heo
2025-08-21 18:00 ` Julian Sun
2025-08-21 18:16 ` Julian Sun
2025-08-21 19:01 ` Tejun Heo
2025-08-22 8:22 ` Julian Sun
2025-08-22 17:56 ` Tejun Heo
2025-08-23 6:18 ` Julian Sun
2025-08-23 8:08 ` Giorgi Tchankvetadze
2025-08-23 8:22 ` Julian Sun
2025-08-23 14:08 ` Giorgi Tchankvetadze
2025-08-23 15:17 ` Julian Sun
2025-08-25 17:45 ` Julian Sun
2025-08-25 18:53 ` Tejun Heo
2025-08-25 19:06 ` Julian Sun
2025-08-25 10:13 ` Jan Kara
2025-08-25 12:08 ` Julian Sun
2025-08-25 18:57 ` [External] " Tejun Heo
2025-08-20 12:16 ` [PATCH 0/3] memcg, writeback: Don't wait writeback completion Giorgi Tchankvetadze
2025-08-21 2:37 ` [External] " Julian Sun
2025-08-22 9:29 ` Giorgi Tchankvetadze [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=e5ef25e7-e4bd-40d4-9f0a-f1d4c1c8acbe@gmail.com \
--to=giorgitchankvetadze1997@gmail.com \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.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=viro@zeniv.linux.org.uk \
/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).