From: <dan.j.williams@intel.com>
To: "Huang, Ying" <ying.huang@linux.alibaba.com>,
Dan Williams <dan.j.williams@intel.com>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Davidlohr Bueso <dave@stgolabs.net>, <dave.jiang@intel.com>,
<alison.schofield@intel.com>, <ira.weiny@intel.com>,
<vishal.l.verma@intel.com>, <seven.yi.lee@gmail.com>,
<hch@infradead.org>, <a.manzanares@samsung.com>,
<fan.ni@samsung.com>
Cc: <linux-cxl@vger.kernel.org>
Subject: Re: Deep flush support for CXL pmem?
Date: Fri, 17 Oct 2025 12:10:39 -0700 [thread overview]
Message-ID: <68f294af24168_2a201001c@dwillia2-mobl4.notmuch> (raw)
In-Reply-To: <87zf9qf46z.fsf@DESKTOP-5N7EMDA>
Huang, Ying wrote:
> Hi, All,
>
> When reading the documentation of PMDK (https://github.com/pmem/pmdk), I
> found that deep flush is used for data loss recovery in addition to GPF.
> With that, we can identify that a file isn't affected by the GPF failure
> because it wasn't opened during the GPF failure.
>
> However, IIUC, the Linux kernel doesn't support deep flush (via
> nvdimm_flush()) for CXL pmem at least for now. For NVDIMM, we have WPQ,
> but it appears that we don't have that for CXL. Is deep flush for CXL
> defined in some spec?
No, and I think a dynamic "deep flush" mechanism is a mistake that CXL
should not pursue. (personal opinion, not necessarily opinion of
$employer)
"All storage is a lie" applies here in that all a deep flush mechanism
does is maybe reduce the occurrence of dirty-shutdown failures. It can
not guarantee that some other event causes the write to be dropped.
CXL does have a Global Persistence Flush mechanism that fires as the
system is dying, but it is not something that can be triggered at run
time.
So, either the system has the reserve energy to make sure that all
globally visible writes make it to persistent storage or it does not. If
it does not then it had better arrange for those failures to be flagged
via a dirty shutdown mechanism.
If a platform fires dirty-shutdown events at a significantly higher rate
than say the capacitor-protected write-cache on an SSD, then that feels
like an "improve the hardware" problem, not a "teach the software to
chase writes with a deep flush and hope it helps" problem.
See discussions like this for the last time mapping pmem deep flush was
attempted to be mapped to storage semantics like FUA (Force Unit
Access):
http://lore.kernel.org/YtefnyIvY9OdrVU5@infradead.org
next prev parent reply other threads:[~2025-10-18 2:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-17 6:11 Deep flush support for CXL pmem? Huang, Ying
2025-10-17 14:25 ` Gregory Price
2025-10-17 17:00 ` Jonathan Cameron
2025-10-17 19:10 ` dan.j.williams [this message]
2025-10-20 2:38 ` Davidlohr Bueso
2025-10-20 11:14 ` Huang, Ying
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=68f294af24168_2a201001c@dwillia2-mobl4.notmuch \
--to=dan.j.williams@intel.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=a.manzanares@samsung.com \
--cc=alison.schofield@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=fan.ni@samsung.com \
--cc=hch@infradead.org \
--cc=ira.weiny@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=seven.yi.lee@gmail.com \
--cc=vishal.l.verma@intel.com \
--cc=ying.huang@linux.alibaba.com \
/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