Re: [PATCH v2 0/2] xfs: skip redundant fsync cache flushes

[Dave Chinner <dgc@kernel.org>]

On Wed, Nov 11, 2026 at 12:17:10PM +0900, Daejun Park via B4 Relay wrote:
> Concurrent fsyncs often wait for an iclog that another task wrote out,
> and then send their own cache flush. Patch 1 numbers the cache flushes
> on each buftarg. Patch 2 uses the numbers to skip that flush when a
> later flush has completed.
> 
> 16 fio jobs of 4k append + fsync in a QEMU guest: 1111 -> 4498
> fsyncs/s.

Ok, the number looks good, but IMO that's a very low number of
concurrent fsyncs in general terms.

Typically the journal doesn't start to bottleneck until there
are hundreds to thousands of concurrent fsyncs and/or synchronous
transaction commits running at once. NFS servers are typical for
this, where there can be thousands of in-flight modifications that
each require require ->commit_metadata to fsync changes before the
server returns the response.

In the past, I have used dbench with increasing number of clients
(into the thousands) to stress fsync/log force behaviour and
scalability. The journal has historically topped out at somewhere
around 20,000 forced log writes a second. It hits that limit when
the built in batching (don't send the current iclog for write when
not full if the previous one is still syncing) is not longer
effective at reducing the number of iclog writes the log forcing
load is driving....

Hence the numbers look promising for low concurrency fsync
workloads, but I'd really like to know waht happens at the high end
when log force count rather than per-file fsync latency is the
performance limiting factor. I suspect that it will improve
performance by further mitigating the number of log writes and/or
cache flushes that need to be done, but it really needs to be
tested....

I'd also like to know how this affects storage that does not require
cache flushes - in those cases flushes are no-ops, so all this
tracking and sequencing would likely be pure overhead....

Cheers,

Dave.
-- 
Dave Chinner
dgc@kernel.org