Re: Really bad I/O lock contention between non-overlapping reader and writer

[Dave Chinner <dgc@kernel.org>]

On Wed, Oct 14, 2026 at 04:10:30PM -0700, Vitali Lovich wrote:
> Ok. I have a patch series I'm happy to share. It has no meaningful
> performance degradation / scaling problems and largely fixes the
> head-of-line blocking problem without the challenges of range
> tracking. Before I post it, some stylistic questions for you:
> 
> * Do you prefer it as a new RFC e-mail chain or continue here

New patch series.

> * Are there specific benchmarks / workloads you'd like me to gather numbers?

FIO exercising random rw 4kB DIO at differing levels of concurrency
is the minimum.

> * Is a VM with RAM XFS filesystem sufficient or is raw metal w/ an
> NVMe drive required?

I'd typically test this on a machine with 32+ CPU cores and an IO
subsystem that can sustain >2 million random 4kB writes
indefinitely. I'd then use fio using pre-written files to hit it
with increasing IO concurrency to the same file with either io_uring
or AIO with direct IO to exercise shared access scalability.

And I'd do this with both the current code (rwsem) and whatever new
locking technique I am testing. The key point here is having enough
CPU cores in the machine to demonstrate the effect of contention on
shared structures.

I also wrote a bunch of micro-benchmarks to stress overlapping IO to
ensure that exclusion occurred correctly, as well as to test
scalability when overlapping range operations are occurring. e.g.
what happens when you have lots of IO in progress, and you do an
operation that needs exclusive access to the entire file (e.g.
FICLONE on an active file).

i.e. demonstration of worst case behaviour is needed because that is
often more important than best case benchmarketing numbers.

-Dave.
-- 
Dave Chinner
dgc@kernel.org