On 6/6/2016 3:46 PM, Dan Williams wrote: > On Mon, Jun 6, 2016 at 12:36 PM, Linda Knippers <linda.knipp...@hpe.com> > wrote: >> >> >> On 6/6/2016 3:31 PM, Dan Williams wrote: >>> On Mon, Jun 6, 2016 at 12:25 PM, Linda Knippers <linda.knipp...@hpe.com> >>> wrote: >>>> On 6/4/2016 4:52 PM, Dan Williams wrote: >>>>> There are scenarios where we need a middle ground between disabling all >>>>> manual bind/unbind attempts (via driver->suppress_bind_attrs) and >>>>> allowing unbind at any userspace-determined time. Pinning modules takes >>>>> away one vector for unwanted out-of-sequence device_release_driver() >>>>> invocations, this new mechanism (via device->suppress_unbind_attr) takes >>>>> away another. >>>>> >>>>> The first user of this mechanism is the libnvdimm sub-system where >>>>> manual dimm disabling should be prevented while the dimm is active in >>>>> any region. Note that there is a 1:N dimm-to-region relationship which >>>>> is why this is implemented as a disable count rather than a flag. This >>>>> forces userspace to disable regions before dimms when manually shutting >>>>> down a bus topology. >>>> >>>> How is this related to deprecating pcommit? >>> >>> We need guarantees that the flush hint mappings are valid for the >>> duration of a pmem namespace being enabled. I am going to move the >>> mapping of the flush hint region from per-dimm to per-region. However >>> since multiple regions may reference the same dimm the mapping needs >>> to be reference counted and shared across regions. This will be >>> similar to the arrangement we have for BLK-regions that share a >>> control region mapping. >> >> Why are things moving around? Aren't flush hints defined per NFIT device >> handle, making them an optional per-dimm thing? >> >> I don't understand a lot of this patch series and had the same questions >> as Jeff. How does deprecating pcommit, because it's not necessary with ADR, >> change so much? > > This patch set deprecates pcommit, and introduces the usage of flush > hints into the pmem path. The introduction patch used the word > "usually", I should have fleshed that out to say "usually ADR, or > explicit use of flush hints". > > A solution to the posted-write-queue flushing needs to be available > and a platform can choose to use flush hints or ADR. If the NFIT > defines an NVDIMM device without hints we assume the platform must > have ADR. If the platform NFIT neglects to define an NVDIMM to > physical address range mapping, we warn about a potentially broken > BIOS. Hopefully we can make this clearer in future versions of the > spec.
You lost me on those last 2 sentences. An NVDIMM doesn't have to have an SPA range, but that seems to be unrelated to pcommit or flushes. -- ljk
