Re: [PATCH v3 0/2] writeback: let foreign flushes reach dying cgwbs

[Jan Kara]

Hello!

On Tue 29-09-26 09:32:01, Tejun Heo wrote:
> On Tue, Sep 29, 2026 at 01:40:49AM +0000, Liz Fong-Jones wrote:
> > 1.5s and 19.5s with it), because writing back the old wb's backlog took
> > up to 27s and the sibling's foreign flushes reached the new wb in the
> > meantime. Should foreign flushes also reach a replaced wb until it is
> > clean, or is that not worth it for this case?
> 
> I don't think the old wb needs to stay reachable if the new wb takes
> over its inodes. Instead of kicking writeback, can the takeover queue a
> work item which switches all of the old wb's inodes to the new wb, like
> cleanup_offline_cgwb() does for b_attached and b_dirty_time? The switch
> carries the dirty and writeback page counts, so foreign flushes reach
> the inodes through the new wb and nothing needs to be flushed right
> away.
> 
> That would also mean switching inodes on b_dirty, b_io and b_more_io
> while the flusher may be working on the old wb, which I'm not sure is
> safe. Jan, would that be okay?

The catch with these things is always to make sure that things like sync(2)
or sync_fs(2) don't miss inodes that are being switched because workers on
different wbs work independently. But these days we have wb_switch_rwsem
so switching of cgwb should be safe against racing sync_inodes_sb(). 

Another possible concern is that writeback workers assume they are the sole
party responsible for changing to which wb list inode is added, at least as
long as I_SYNC_QUEUED flag is set. But again AFAICS
process_inode_switch_wbs() takes care of all the locking properly and even
currently, switches could happen while writeback is in progress when the
inode's owner wb changes. So this should be fine.

Finally, I'd be concerned about the performance of inode_do_switch_wbs()
when we are switching many inodes with potentially many dirty folios. It's
going to be a lot of stat item updates... With this I'm not sure how much
it will matter in practice but since we'll burn those CPU cycles when doing
writeback as well, probably it won't be too bad.

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR