From: Breno Leitao <leitao@debian.org>
To: Jan Kara <jack@suse.cz>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>,
Julian Sun <sunjunchao@bytedance.com>,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>,
Muchun Song <muchun.song@linux.dev>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, cgroups@vger.kernel.org,
kernel-team@meta.com
Subject: Re: [PATCH 4/4] writeback: report a slow writeback wait once per timeout
Date: Fri, 6 Nov 2026 07:47:22 -0800 [thread overview]
Message-ID: <au3w4xiaYbEYLTru@gmail.com> (raw)
In-Reply-To: <ysxh2sfvjikoh6cw2qmk2i6p7xripwnqxkx43jj7unxop5tkiw@gws5wezjt34g>
On Fri, Nov 06, 2026 at 03:37:45PM +0100, Jan Kara wrote:
> On Fri 06-11-26 04:26:34, Breno Leitao wrote:
> > The slow writeback report is printed on every wakeup of the waiter past
> > hung_task_timeout_secs, and the waiter is woken more often than that.
> >
> > Each flusher working for it wakes it once it has not run for half the
> > timeout. All waiters on a bdi share bdi->wb_waitq, so a wakeup meant for
> > one of them reaches all of them.
> >
> > A sync of files dirtied from two cgroups, on a throttled null_blk device
> > with the timeout set to 5 seconds, gets a report every half timeout,
> > each printed twice, 18 reports for a 29 second wait:
> >
> > [ 10.327992] INFO: The task sync:276 has been waiting for writeback completion for more than 8 seconds.
> > [ 10.328000] bdi 252:0, work items left: 2
> > [ 10.328003] INFO: The task sync:276 has been waiting for writeback completion for more than 8 seconds.
> > [ 10.328004] bdi 252:0, work items left: 2
> > [ 12.888187] INFO: The task sync:276 has been waiting for writeback completion for more than 10 seconds.
> > [ 12.888195] bdi 252:0, work items left: 2
> > [ 12.888197] INFO: The task sync:276 has been waiting for writeback completion for more than 10 seconds.
> > [ 12.888198] bdi 252:0, work items left: 2
> > ...
> >
> > Remember when the waiter last reported, and report again only once
> > another timeout has passed. The wakeups do not change, so the hung task
> > detector still sees the waiter making progress. The same test now
> > prints 5 reports:
> >
> > [ 7.661129] INFO: The task sync:277 has been waiting for writeback completion for more than 5 seconds.
> > [ 7.661136] bdi 252:0, work items left: 2
> > [ 13.241102] INFO: The task sync:277 has been waiting for writeback completion for more than 11 seconds.
> > [ 13.241109] bdi 252:0, work items left: 2
> > ...
> > [ 31.801068] The task sync:277 waited 29 seconds for writeback completion on bdi 252:0
> >
> > Signed-off-by: Breno Leitao <leitao@debian.org>
>
> Now I'm waiting for someone to complain it gets written out too
> infrequently :).
Once per timeout is also how often the hung task detector checks by
default, and patch 3 logs the total once the wait ends, so maybe that is
exactly what people need? Not sure.
> Is this change substantially different from
> writeback_sb_inodes() waking up done->waitq less frequently?
You mean the ->progress_stamp field? That is not used for reporting
purposes, right? Should it be?
It could drop the duplicates: a wakeup with work left runs the
wait_event() condition twice (since 84654c7f4730, it is checked right
after schedule() and again after prepare_to_wait_event()), and the
second check would find ->progress_stamp just refreshed by the first.
But the waiter refreshes ->progress_stamp on every wakeup, so it cannot
space the reports further apart than the wakeups, and those have to
come more often than the hung task timeout.
So it is a choice between a report every half timeout with no new
field, or once per timeout with report_stamp. Which one do you prefer?
Thanks for the review,
--breno
next prev parent reply other threads:[~2026-11-06 15:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-06 12:26 [PATCH 0/4] writeback: make slow writeback report more actionable Breno Leitao
2026-11-06 12:26 ` [PATCH 1/4] writeback: add the missing newline to the slow writeback report Breno Leitao
2026-11-06 14:18 ` Jan Kara
2026-11-06 12:26 ` [PATCH 2/4] writeback: name the bdi in " Breno Leitao
2026-11-06 14:27 ` Jan Kara
2026-11-06 15:48 ` Breno Leitao
2026-11-06 12:26 ` [PATCH 3/4] writeback: log the end of a slow writeback wait Breno Leitao
2026-11-06 14:29 ` Jan Kara
2026-11-06 12:26 ` [PATCH 4/4] writeback: report a slow writeback wait once per timeout Breno Leitao
2026-11-06 14:37 ` Jan Kara
2026-11-06 15:47 ` Breno Leitao [this message]
2026-11-09 14:12 ` Jan Kara
2026-11-09 16:44 ` Breno Leitao
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=au3w4xiaYbEYLTru@gmail.com \
--to=leitao@debian.org \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=jack@suse.cz \
--cc=kernel-team@meta.com \
--cc=liam@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=rppt@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=sunjunchao@bytedance.com \
--cc=surenb@google.com \
--cc=vbabka@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 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.