mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Erwan Velu <e.velu@criteo.com>
To: Keith Busch <kbusch@kernel.org>
Cc: linux-nvme@lists.infradead.org, axboe@kernel.dk, hch@lst.de,
	sagi@grimberg.me, linux-kernel@vger.kernel.org,
	Erwan Velu <erwanaliasr1@gmail.com>
Subject: Re: [PATCH] nvme: honor the volatile write cache enable state
Date: Fri, 23 Oct 2026 16:53:54 +0200	[thread overview]
Message-ID: <7fec6534-9e57-4041-8699-72c5950c7e2a@criteo.com> (raw)
In-Reply-To: <atqZmctbU0siYmVX@kbusch-mbp>


On 10/23/26 01:17, Keith Busch wrote:
[...]
> I just wanted to see if there was any difference in the controller's
> Flush behavior when the volatile cache was enabled vs disabled, and this
> looks like it's the same either way. The Flush should have been a no-op
> to the device with WCE cleared, so something seems off here.
>
> I'm wondering if the device is actually really respecting WCE set to 0
> now. That might be tricky to prove, but it wouldn't be the first time a
> device lied  about durability. Not saying that's happening here, but the
> behavior you're reporting is suspicious: 15usec writes are not
> physically possible with TLC NAND (your model says BiCS TLC) without a
> cache, and your controller says your cache is volatile.
>
> Anyway, the principle of what you're proposing looks fine to me from a
> spec standpoint. I'll get this queued up if I don't see any other review
> feedback or concerns that it's going to corrupt something...

Thanks for your feedback.

I'll discuss this firmware question with the vendor in private and will 
keep you aware.

Considering the performance impact for these type of device,s would you 
be open to a backport to stable once merged ?

This patch is really about matching the spec and it would be probably a 
great positive impact for many stable users to benefit from this patch.

WDYT ?

Erwan,


  reply	other threads:[~2026-10-23 14:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-16 14:12 Erwan Velu
2026-10-16 16:57 ` Keith Busch
2026-10-16 17:15   ` Erwan Velu
2026-10-16 17:27     ` Keith Busch
2026-10-16 17:43       ` Erwan Velu
2026-10-16 17:55         ` Keith Busch
2026-10-17  4:25           ` Erwan Velu
2026-10-22 13:27             ` Erwan Velu
2026-10-22 23:17               ` Keith Busch
2026-10-23 14:53                 ` Erwan Velu [this message]
2026-10-28 16:08                   ` Keith Busch
2026-10-28 16:16                     ` Christoph Hellwig
2026-10-28 17:08                     ` Erwan Velu
2026-10-28 17:47                       ` Keith Busch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7fec6534-9e57-4041-8699-72c5950c7e2a@criteo.com \
    --to=e.velu@criteo.com \
    --cc=axboe@kernel.dk \
    --cc=erwanaliasr1@gmail.com \
    --cc=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®