From: Tejun Heo <tj@kernel.org>
To: Liz Fong-Jones <lizf@honeycomb.io>
Cc: Jan Kara <jack@suse.cz>, Christian Brauner <brauner@kernel.org>,
"Patrick Lu (Anthropic)" <perf.patrick.lu@gmail.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
ian@honeycomb.io
Subject: Re: [PATCH] writeback: keep cleanup_offline_cgwb()'s scan out of syncs
Date: Fri, 16 Oct 2026 11:28:24 -1000 [thread overview]
Message-ID: <29b280c82730b879e5f3ccdb35639ead@kernel.org> (raw)
In-Reply-To: <20261015114307.1041273-1-lizf@honeycomb.io>
Hello, Liz.
On Thu, Oct 15, 2026 at 11:43:09AM +0000, Liz Fong-Jones wrote:
> Trigger: a wb has lazytime-dirty inodes on b_dirty_time when a sync
> starts, an inode on it gets a timestamp update after the sync's cutoff,
> and then its memcg (or, if the wb is already dying, any memcg) is
> removed, which runs cleanup_offline_cgwb() on it before the sync work
> queues inodes.
The late inode has to be one without a pending lazytime update. One
already on b_dirty_time keeps its position and dirtied_when.
cleanup_offline_cgwbs_workfn() skips wbs with anything on b_dirty, b_io
or b_more_io. So the scan has to land between wb_writeback() fixing
dirtied_before and taking list_lock for the first queue_io(), which is a
few instructions. The exception is a multi-pass drain that started
before the wb got dirty IO, as the loop doesn't recheck. Maybe say that
the window is narrow so that stable can weigh it?
> Once an isw fills before the scan reaches a newer inode, or a later pass
> walks past it, older inodes land in front of it on b_dirty_time.
A pass keeps the inodes it walks in order, so the only reordering is
between the walked inodes and the ones a filled pass didn't reach. "or a
later pass walks past it" doesn't seem to be a separate case.
> Tejun spotted this reordering racing with a sync on b_dirty in a patch
> under review and suggested holding wb_switch_rwsem for read across that
> scan [1]. cleanup_offline_cgwb()'s scan of b_dirty_time needs the same.
The description is pretty long for a six-line fix. Maybe drop this
paragraph, which Suggested-by and Link already cover, move the test
details below ---, and tighten the rest?
> + /*
> + * The scan reorders b_dirty_time. Keep it out of a sync's way, which
> + * could otherwise miss timestamps moved past its cutoff.
> + */
The inodes' dirtied_when doesn't change. What moves is their list
position. Maybe something like:
/*
* The scan moves walked inodes to the newest end of b_dirty_time,
* past ones it didn't reach. If one of those was dirtied after a
* sync's cutoff, the sync's queue_io() stops there and misses the
* moved ones. Exclude syncs as process_inode_switch_wbs() does.
*/
None of the above is blocking.
Acked-by: Tejun Heo <tj@kernel.org>
Thanks.
--
tejun
next prev parent reply other threads:[~2026-10-16 21:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 11:43 [PATCH] writeback: keep cleanup_offline_cgwb()'s scan out of syncs Liz Fong-Jones
2026-10-16 21:28 ` Tejun Heo [this message]
2026-10-17 4:07 ` [PATCH v2] " Liz Fong-Jones
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=29b280c82730b879e5f3ccdb35639ead@kernel.org \
--to=tj@kernel.org \
--cc=brauner@kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=ian@honeycomb.io \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizf@honeycomb.io \
--cc=perf.patrick.lu@gmail.com \
--cc=roman.gushchin@linux.dev \
--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.