Re: [PATCH] nvme: honor the volatile write cache enable state

[Erwan Velu]

Le ven. 16 oct. 2026 à 18:57, Keith Busch <kbusch@xxxxxxxxxx> a écrit :
>
> On Fri, Oct 16, 2026 at 04:12:08PM +0200, Erwan Velu wrote:
> >   job                   | cache   |   IOPS | fsync avg | flushes |  gain
> >   ----------------------+---------+--------+-----------+---------+------
> >   psync buffered, QD1   | back    |   3885 |   247.6us |  116552 |
> >                         | through |  48325 |    15.7us |       0 | x12.4
> >   ----------------------+---------+--------+-----------+---------+------
> >   io_uring direct, QD1  | back    |   3886 |   238.2us |  116593 |
> >                         | through |  41924 |     5.7us |       0 | x10.8
> >   ----------------------+---------+--------+-----------+---------+------
> >   io_uring direct, QD32 | back    |   5088 |  6173.5us |  117793 |
> >                         | through | 140196 |   107.0us |       0 | x27.6
> >
> > From NVMe 1.4c (sections 5.21.1.6 and 6.8) up to the NVMe Base
> > Specification 2.4 (sections 5.2.30.1.4 and 7.2), a Flush command has no
> > effect if the volatile write cache is not enabled.
>
> Yeah, the NVMe Flush operation should be a no-op in the device, so the
> dramatic performance difference is a bit alarming. Surely the block
> stack's flush machinery is not the reason for the difference, right?
>
> If the device's flush handling is this bad when VWC is disabled, what
> happens when you have it enabled? Can you re-run the same test with that
> setting?
>
> I'm not necessarily against what you're proposing here, but your numbers
> are unexpected.

Maybe my table here isn't probably clear enough.
The numbers shown in the  "write back" mode were done with VWC enabled.
The numbers shown in the "write through" mode were done with VWC disabled.

As I'm doing lots of fsync (on purpose in this test by having
--fsync=1 in my fio cmdline), you can see the "flushes" counter is
very high when VWC is enabled.
The impressive numbers (more than 10x) come from this workload : lots
of fsync for little data.
Please note this patch is following an investigation after a report
from one of my users complaining of poor latency on this NVMe drive
series in particular.
So this isn't an unrealistic use case; the impact we see in production
is of the same order of magnitude as what this patch reports.

Erwan,