From: Jeff Moyer <jmoyer@redhat.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: linux-nvdimm@ml01.01.org, david@fromorbit.com,
linux-kernel@vger.kernel.org, hch@lst.de
Subject: Re: [PATCH 03/13] libnvdimm: introduce nvdimm_flush()
Date: Mon, 06 Jun 2016 13:45:36 -0400 [thread overview]
Message-ID: <x498tyijjnj.fsf@segfault.boston.devel.redhat.com> (raw)
In-Reply-To: <146507356876.8347.4735880992775196026.stgit@dwillia2-desk3.amr.corp.intel.com> (Dan Williams's message of "Sat, 04 Jun 2016 13:52:48 -0700")
Dan Williams <dan.j.williams@intel.com> writes:
> nvdimm_flush() is an alternative to the x86 pcommit instruction. It is
> an optional write flushing mechanism that an nvdimm bus can provide for
> the pmem driver to consume. In the case of the NFIT nvdimm-bus-provider
> nvdimm_flush() is implemented as a series of flush-hint-address [1]
> writes to each dimm in the interleave set that backs the namespace. For
> now this implementation is just a simple replacement of wmb_pmem() /
> arch_has_wmb_pmem() with nvdimm_flush() / nvdimm_has_flush().
Dan, this needs a whole heck of a lot more explanation. As I understand
it, you're talking about flushing write pending queues (not the CPU
cache). And given that the write pending queues are part of the
persistence domain on systems with ADR (now required for pmem), they
don't need to be flushed for normal pmem, only for block window
accesses. And so this confuses me:
> We defer the full implementation of nvdimm_flush() until the
>implementation is prepared to also handle the blk-region case.
The one thing they're required to address is not addressed? I
understand that you may want to push data out as far as possible to
limit the exposure to hardware failures, but that's not how you're
positioning this patch, and so it's very confusing.
Please also make the documentation above nvdimm_flush and
nvdimm_has_flush much more idiot-proof.
> @@ -234,7 +249,7 @@ static int pmem_attach_disk(struct device *dev,
> dev_set_drvdata(dev, pmem);
> pmem->phys_addr = res->start;
> pmem->size = resource_size(res);
> - if (!arch_has_wmb_pmem())
> + if (nvdimm_has_flush(nd_region) < 0)
> dev_warn(dev, "unable to guarantee persistence of writes\n");
And this doesn't make sense to me, either. NVDIMM-N's do not have to
have flush hint addresses in order to guarantee persistence. I guess
that's no different than what we have now, but you're sure not
addressing this bogus warning message. And yes, I know there's no way
to query the platform to see if ADR is available. But how many people
do you think are sticking NVDIMM-Ns in systems that do not have ADR?
Just get rid of the message already.
Cheers,
Jeff
next prev parent reply other threads:[~2016-06-06 17:45 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-04 20:52 [PATCH 00/13] deprecate pcommit Dan Williams
2016-06-04 20:52 ` [PATCH 01/13] driver core, libnvdimm: disable manual unbind of dimms while region active Dan Williams
2016-06-04 21:10 ` Greg Kroah-Hartman
2016-06-04 21:39 ` Dan Williams
2016-06-04 21:45 ` Greg Kroah-Hartman
2016-06-04 21:48 ` Dan Williams
2016-06-04 21:50 ` kbuild test robot
2016-06-06 19:25 ` Linda Knippers
2016-06-06 19:31 ` Dan Williams
2016-06-06 19:36 ` Dan Williams
2016-06-06 19:36 ` Linda Knippers
2016-06-06 19:46 ` Dan Williams
2016-06-06 20:20 ` Linda Knippers
2016-06-06 20:36 ` Dan Williams
2016-06-06 21:15 ` Linda Knippers
2016-06-04 20:52 ` [PATCH 02/13] nfit: always associate flush hints Dan Williams
2016-06-04 20:52 ` [PATCH 03/13] libnvdimm: introduce nvdimm_flush() Dan Williams
2016-06-06 17:45 ` Jeff Moyer [this message]
2016-06-04 20:52 ` [PATCH 04/13] libnvdimm, nfit: move flush hint mapping to dimm driver Dan Williams
2016-06-04 21:29 ` kbuild test robot
2016-06-04 21:40 ` kbuild test robot
2016-06-04 21:49 ` kbuild test robot
2016-06-07 18:11 ` Kani, Toshimitsu
2016-06-07 18:15 ` Dan Williams
2016-06-04 20:52 ` [PATCH 05/13] tools/testing/nvdimm: simulate multiple flush hints per-dimm Dan Williams
2016-06-04 20:53 ` [PATCH 06/13] libnvdimm: cycle flush hints per-cpu Dan Williams
2016-06-04 20:53 ` [PATCH 07/13] libnvdimm, pmem: use REQ_FUA, REQ_FLUSH for nvdimm_flush() Dan Williams
2016-06-04 20:53 ` [PATCH 08/13] fs/dax: remove wmb_pmem() Dan Williams
2016-06-04 20:53 ` [PATCH 09/13] libnvdimm, pmem: use nvdimm_flush() for namespace I/O writes Dan Williams
2016-06-04 20:53 ` [PATCH 10/13] pmem: kill wmb_pmem() Dan Williams
2016-06-04 20:53 ` [PATCH 11/13] Revert "KVM: x86: add pcommit support" Dan Williams
2016-06-06 15:14 ` Paolo Bonzini
2016-06-06 16:14 ` Dan Williams
2016-06-04 20:53 ` [PATCH 12/13] x86/insn: remove pcommit Dan Williams
2016-06-04 20:53 ` [PATCH 13/13] pmem: kill __pmem address space Dan Williams
2016-06-04 22:18 ` kbuild test robot
2016-06-05 17:41 ` [PATCH 00/13] deprecate pcommit Andy Lutomirski
2016-06-05 18:48 ` Rudoff, Andy
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=x498tyijjnj.fsf@segfault.boston.devel.redhat.com \
--to=jmoyer@redhat.com \
--cc=dan.j.williams@intel.com \
--cc=david@fromorbit.com \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@ml01.01.org \
/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