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

[Keith Busch]

On Fri, Oct 16, 2026 at 07:15:20PM +0200, Erwan Velu wrote:
> Le ven. 16 oct. 2026 à 18:57, Keith Busch <kbusch at kernel.org> 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.

But you said the table came from tests "with WCE cleared" in the VWC
feature. ?