| Message ID | 149315140303.23340.14688142799059150805.stgit@dwillia2-desk3.amr.corp.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Dan Williams <dan.j.williams@intel.com> writes: > The nvdimm_flush() mechanism helps to reduce the impact of an ADR > (asynchronous-dimm-refresh) failure. The ADR mechanism handles flushing > platform WPQ (write-pending-queue) buffers when power is removed. The > nvdimm_flush() mechanism performs that same function on-demand. > > When a pmem namespace is associated with a block device, an > nvdimm_flush() is triggered with every block-layer REQ_FUA, or REQ_FLUSH > request. These requests are typically associated with filesystem > metadata updates. However, when a namespace is in device-dax mode, > userspace (think database metadata) needs another path to perform the > same flushing. In other words this is not required to make data > persistent, but in the case of metadata it allows for a smaller failure > domain in the unlikely event of an ADR failure. > > The new 'flush' attribute is visible when the individual DIMMs backing a > given interleave-set are described by platform firmware. In ACPI terms > this is "NVDIMM Region Mapping Structures" and associated "Flush Hint > Address Structures". Reads return "1" if the region supports triggering > WPQ flushes on all DIMMs. Reads return "0" the flush operation is a > platform nop, and in that case the attribute is read-only. I can make peace with exposing this to userspace, though I am mostly against its use. However, sysfs feels like the wrong interface. Believe it or not, I'd rather see this implemented as an ioctl. This isn't a NACK, it's me giving my opinion. Do with it what you will. Cheers, Jeff
On Wed, Apr 26, 2017 at 1:38 PM, Jeff Moyer <jmoyer@redhat.com> wrote: > Dan Williams <dan.j.williams@intel.com> writes: > >> The nvdimm_flush() mechanism helps to reduce the impact of an ADR >> (asynchronous-dimm-refresh) failure. The ADR mechanism handles flushing >> platform WPQ (write-pending-queue) buffers when power is removed. The >> nvdimm_flush() mechanism performs that same function on-demand. >> >> When a pmem namespace is associated with a block device, an >> nvdimm_flush() is triggered with every block-layer REQ_FUA, or REQ_FLUSH >> request. These requests are typically associated with filesystem >> metadata updates. However, when a namespace is in device-dax mode, >> userspace (think database metadata) needs another path to perform the >> same flushing. In other words this is not required to make data >> persistent, but in the case of metadata it allows for a smaller failure >> domain in the unlikely event of an ADR failure. >> >> The new 'flush' attribute is visible when the individual DIMMs backing a >> given interleave-set are described by platform firmware. In ACPI terms >> this is "NVDIMM Region Mapping Structures" and associated "Flush Hint >> Address Structures". Reads return "1" if the region supports triggering >> WPQ flushes on all DIMMs. Reads return "0" the flush operation is a >> platform nop, and in that case the attribute is read-only. > > I can make peace with exposing this to userspace, though I am mostly > against its use. However, sysfs feels like the wrong interface. > Believe it or not, I'd rather see this implemented as an ioctl. > > This isn't a NACK, it's me giving my opinion. Do with it what you will. I hate ioctls with a burning passion so I can't get on board with that change, but perhaps the sentiment behind it is that this is too visible and too attractive being called "flush" in sysfs? Would a name more specific to the mechanism make it more palatable? Like "flush_hint_trigger" or "wpq_drain"?
Dan Williams <dan.j.williams@intel.com> writes: > On Wed, Apr 26, 2017 at 1:38 PM, Jeff Moyer <jmoyer@redhat.com> wrote: >> Dan Williams <dan.j.williams@intel.com> writes: >> >>> The nvdimm_flush() mechanism helps to reduce the impact of an ADR >>> (asynchronous-dimm-refresh) failure. The ADR mechanism handles flushing >>> platform WPQ (write-pending-queue) buffers when power is removed. The >>> nvdimm_flush() mechanism performs that same function on-demand. >>> >>> When a pmem namespace is associated with a block device, an >>> nvdimm_flush() is triggered with every block-layer REQ_FUA, or REQ_FLUSH >>> request. These requests are typically associated with filesystem >>> metadata updates. However, when a namespace is in device-dax mode, >>> userspace (think database metadata) needs another path to perform the >>> same flushing. In other words this is not required to make data >>> persistent, but in the case of metadata it allows for a smaller failure >>> domain in the unlikely event of an ADR failure. >>> >>> The new 'flush' attribute is visible when the individual DIMMs backing a >>> given interleave-set are described by platform firmware. In ACPI terms >>> this is "NVDIMM Region Mapping Structures" and associated "Flush Hint >>> Address Structures". Reads return "1" if the region supports triggering >>> WPQ flushes on all DIMMs. Reads return "0" the flush operation is a >>> platform nop, and in that case the attribute is read-only. >> >> I can make peace with exposing this to userspace, though I am mostly >> against its use. However, sysfs feels like the wrong interface. >> Believe it or not, I'd rather see this implemented as an ioctl. >> >> This isn't a NACK, it's me giving my opinion. Do with it what you will. > > I hate ioctls with a burning passion so I can't get on board with that > change, but perhaps the sentiment behind it is that this is too > visible and too attractive being called "flush" in sysfs? Would a name > more specific to the mechanism make it more palatable? Like > "flush_hint_trigger" or "wpq_drain"? The sentiment is that programs shouldn't have to grovel around in sysfs to do stuff related to an open file descriptor or mapping. I don't take issue with the name. I do worry that something like 'wpq_drain' may be too platform specific, though. The NVM Programming Model specification is going to call this "deep flush", so maybe that will give you some inspiration if you do want to change the name. Cheers, Jeff
On Thu, Apr 27, 2017 at 6:45 AM, Jeff Moyer <jmoyer@redhat.com> wrote: > Dan Williams <dan.j.williams@intel.com> writes: > >> On Wed, Apr 26, 2017 at 1:38 PM, Jeff Moyer <jmoyer@redhat.com> wrote: >>> Dan Williams <dan.j.williams@intel.com> writes: >>> >>>> The nvdimm_flush() mechanism helps to reduce the impact of an ADR >>>> (asynchronous-dimm-refresh) failure. The ADR mechanism handles flushing >>>> platform WPQ (write-pending-queue) buffers when power is removed. The >>>> nvdimm_flush() mechanism performs that same function on-demand. >>>> >>>> When a pmem namespace is associated with a block device, an >>>> nvdimm_flush() is triggered with every block-layer REQ_FUA, or REQ_FLUSH >>>> request. These requests are typically associated with filesystem >>>> metadata updates. However, when a namespace is in device-dax mode, >>>> userspace (think database metadata) needs another path to perform the >>>> same flushing. In other words this is not required to make data >>>> persistent, but in the case of metadata it allows for a smaller failure >>>> domain in the unlikely event of an ADR failure. >>>> >>>> The new 'flush' attribute is visible when the individual DIMMs backing a >>>> given interleave-set are described by platform firmware. In ACPI terms >>>> this is "NVDIMM Region Mapping Structures" and associated "Flush Hint >>>> Address Structures". Reads return "1" if the region supports triggering >>>> WPQ flushes on all DIMMs. Reads return "0" the flush operation is a >>>> platform nop, and in that case the attribute is read-only. >>> >>> I can make peace with exposing this to userspace, though I am mostly >>> against its use. However, sysfs feels like the wrong interface. >>> Believe it or not, I'd rather see this implemented as an ioctl. >>> >>> This isn't a NACK, it's me giving my opinion. Do with it what you will. >> >> I hate ioctls with a burning passion so I can't get on board with that >> change, but perhaps the sentiment behind it is that this is too >> visible and too attractive being called "flush" in sysfs? Would a name >> more specific to the mechanism make it more palatable? Like >> "flush_hint_trigger" or "wpq_drain"? > > The sentiment is that programs shouldn't have to grovel around in sysfs > to do stuff related to an open file descriptor or mapping. I don't take > issue with the name. I do worry that something like 'wpq_drain' may be > too platform specific, though. The NVM Programming Model specification > is going to call this "deep flush", so maybe that will give you > some inspiration if you do want to change the name. I'll change to "deep_flush", and I quibble that this is related to a single open file descriptor or mapping. It really is a "region flush" for giving extra protection for global metadata, but the persistence of individual fds or mappings is handled by ADR. I think an ioctl might give the false impression that every time you flush a cacheline to persistence you need to call the ioctl.
Dan Williams <dan.j.williams@intel.com> writes: >> The sentiment is that programs shouldn't have to grovel around in sysfs >> to do stuff related to an open file descriptor or mapping. I don't take >> issue with the name. I do worry that something like 'wpq_drain' may be >> too platform specific, though. The NVM Programming Model specification >> is going to call this "deep flush", so maybe that will give you >> some inspiration if you do want to change the name. > > I'll change to "deep_flush", and I quibble that this is related to a > single open file descriptor or mapping. It really is a "region flush" > for giving extra protection for global metadata, but the persistence > of individual fds or mappings is handled by ADR. I think an ioctl > might give the false impression that every time you flush a cacheline > to persistence you need to call the ioctl. fsync, for example, may affect more than one fd--all data in the drive write cache will be flushed. I don't see how this is so different. I think a sysfs file is awkward because it requires an application to chase down the correct file in the sysfs hierarchy. If the application already has an open fd or a mapping, it should be able to operate on that. As for confusion on when to use the interface, I think that's inevitable no matter how it's implemented. We're introducing a flush type that has never been exposed before, and we're not giving any information on how likely an ADR failure is, or how expensive this flush will be. Cheers, Jeff
On Thu, Apr 27, 2017 at 11:41 AM, Jeff Moyer <jmoyer@redhat.com> wrote: > Dan Williams <dan.j.williams@intel.com> writes: > >>> The sentiment is that programs shouldn't have to grovel around in sysfs >>> to do stuff related to an open file descriptor or mapping. I don't take >>> issue with the name. I do worry that something like 'wpq_drain' may be >>> too platform specific, though. The NVM Programming Model specification >>> is going to call this "deep flush", so maybe that will give you >>> some inspiration if you do want to change the name. >> >> I'll change to "deep_flush", and I quibble that this is related to a >> single open file descriptor or mapping. It really is a "region flush" >> for giving extra protection for global metadata, but the persistence >> of individual fds or mappings is handled by ADR. I think an ioctl >> might give the false impression that every time you flush a cacheline >> to persistence you need to call the ioctl. > > fsync, for example, may affect more than one fd--all data in the drive > write cache will be flushed. I don't see how this is so different. I > think a sysfs file is awkward because it requires an application to > chase down the correct file in the sysfs hierarchy. If the application > already has an open fd or a mapping, it should be able to operate on > that. I'm teetering, but still leaning towards sysfs. The use case that needs this is device-dax because we otherwise silently do this behind the application's back on filesystem-dax for fsync / msync. A device-dax ioctl would be straightforward, but 'deep flush' assumes that the device-dax instance is fronting persistent memory. There's nothing persistent memory specific about device-dax except that today only the nvdimm sub-system knows how to create them, but there's nothing that prevents other memory regions from being mapped this way. So I'd rather this persistent memory specific mechanism stay with the persistent memory specific portion of the interface rather than plumb persistent memory details out through the generic device-dax interface since we have no other intercept point like we do in the filesystem-dax case to hide this flush.
On Thu, Apr 27, 2017 at 12:17 PM, Dan Williams <dan.j.williams@intel.com> wrote: > On Thu, Apr 27, 2017 at 11:41 AM, Jeff Moyer <jmoyer@redhat.com> wrote: >> Dan Williams <dan.j.williams@intel.com> writes: >> >>>> The sentiment is that programs shouldn't have to grovel around in sysfs >>>> to do stuff related to an open file descriptor or mapping. I don't take >>>> issue with the name. I do worry that something like 'wpq_drain' may be >>>> too platform specific, though. The NVM Programming Model specification >>>> is going to call this "deep flush", so maybe that will give you >>>> some inspiration if you do want to change the name. >>> >>> I'll change to "deep_flush", and I quibble that this is related to a >>> single open file descriptor or mapping. It really is a "region flush" >>> for giving extra protection for global metadata, but the persistence >>> of individual fds or mappings is handled by ADR. I think an ioctl >>> might give the false impression that every time you flush a cacheline >>> to persistence you need to call the ioctl. >> >> fsync, for example, may affect more than one fd--all data in the drive >> write cache will be flushed. I don't see how this is so different. I >> think a sysfs file is awkward because it requires an application to >> chase down the correct file in the sysfs hierarchy. If the application >> already has an open fd or a mapping, it should be able to operate on >> that. > > I'm teetering, but still leaning towards sysfs. The use case that > needs this is device-dax because we otherwise silently do this behind > the application's back on filesystem-dax for fsync / msync. A > device-dax ioctl would be straightforward, but 'deep flush' assumes > that the device-dax instance is fronting persistent memory. There's > nothing persistent memory specific about device-dax except that today > only the nvdimm sub-system knows how to create them, but there's > nothing that prevents other memory regions from being mapped this way. > So I'd rather this persistent memory specific mechanism stay with the > persistent memory specific portion of the interface rather than plumb > persistent memory details out through the generic device-dax interface > since we have no other intercept point like we do in the > filesystem-dax case to hide this flush. We also still seem to need a discovery mechanism as I've had questions about "how do I tell if my system supports deep flush?". That's where sysfs is much better than an ioctl. The need for deep flush discovery tips the scales, at least for me, to also do deep flush triggering through the same interface.
Dan Williams <dan.j.williams@intel.com> writes: > On Thu, Apr 27, 2017 at 11:41 AM, Jeff Moyer <jmoyer@redhat.com> wrote: >> Dan Williams <dan.j.williams@intel.com> writes: >> >>>> The sentiment is that programs shouldn't have to grovel around in sysfs >>>> to do stuff related to an open file descriptor or mapping. I don't take >>>> issue with the name. I do worry that something like 'wpq_drain' may be >>>> too platform specific, though. The NVM Programming Model specification >>>> is going to call this "deep flush", so maybe that will give you >>>> some inspiration if you do want to change the name. >>> >>> I'll change to "deep_flush", and I quibble that this is related to a >>> single open file descriptor or mapping. It really is a "region flush" >>> for giving extra protection for global metadata, but the persistence >>> of individual fds or mappings is handled by ADR. I think an ioctl >>> might give the false impression that every time you flush a cacheline >>> to persistence you need to call the ioctl. >> >> fsync, for example, may affect more than one fd--all data in the drive >> write cache will be flushed. I don't see how this is so different. I >> think a sysfs file is awkward because it requires an application to >> chase down the correct file in the sysfs hierarchy. If the application >> already has an open fd or a mapping, it should be able to operate on >> that. > > I'm teetering, but still leaning towards sysfs. The use case that > needs this is device-dax because we otherwise silently do this behind > the application's back on filesystem-dax for fsync / msync. We may yet get file system support for flush from userspace (NOVA, for example). So I don't think we should restrict ourselves to only thinking about the device dax use case. > A device-dax ioctl would be straightforward, but 'deep flush' assumes > that the device-dax instance is fronting persistent memory. There's > nothing persistent memory specific about device-dax except that today > only the nvdimm sub-system knows how to create them, but there's > nothing that prevents other memory regions from being mapped this way. You're concerned that applications operating on device dax instances that are not backed by pmem will try to issue a deep flush? Why would they do that, and why can't you just return failure from the ioctl? > So I'd rather this persistent memory specific mechanism stay with the > persistent memory specific portion of the interface rather than plumb > persistent memory details out through the generic device-dax interface > since we have no other intercept point like we do in the > filesystem-dax case to hide this flush. Look at the block layer. You can issue an ioctl on a block device, and if the generic block layer can handle it, it does. If not, it gets passed down to lower layers until either it gets handled, or it bubbles back up because nobody knew what to do with it. I think you can do the same thing here, and that solves your layering violation. Cheers, Jeff
Dan Williams <dan.j.williams@intel.com> writes: > We also still seem to need a discovery mechanism as I've had questions > about "how do I tell if my system supports deep flush?". That's where > sysfs is much better than an ioctl. The need for deep flush discovery > tips the scales, at least for me, to also do deep flush triggering > through the same interface. Return ENXIO or EOPNOTSUPP from the ioctl when it isn't supported? Cheers, Jeff
On Thu, Apr 27, 2017 at 12:40 PM, Jeff Moyer <jmoyer@redhat.com> wrote: > Dan Williams <dan.j.williams@intel.com> writes: > >> On Thu, Apr 27, 2017 at 11:41 AM, Jeff Moyer <jmoyer@redhat.com> wrote: >>> Dan Williams <dan.j.williams@intel.com> writes: >>> >>>>> The sentiment is that programs shouldn't have to grovel around in sysfs >>>>> to do stuff related to an open file descriptor or mapping. I don't take >>>>> issue with the name. I do worry that something like 'wpq_drain' may be >>>>> too platform specific, though. The NVM Programming Model specification >>>>> is going to call this "deep flush", so maybe that will give you >>>>> some inspiration if you do want to change the name. >>>> >>>> I'll change to "deep_flush", and I quibble that this is related to a >>>> single open file descriptor or mapping. It really is a "region flush" >>>> for giving extra protection for global metadata, but the persistence >>>> of individual fds or mappings is handled by ADR. I think an ioctl >>>> might give the false impression that every time you flush a cacheline >>>> to persistence you need to call the ioctl. >>> >>> fsync, for example, may affect more than one fd--all data in the drive >>> write cache will be flushed. I don't see how this is so different. I >>> think a sysfs file is awkward because it requires an application to >>> chase down the correct file in the sysfs hierarchy. If the application >>> already has an open fd or a mapping, it should be able to operate on >>> that. >> >> I'm teetering, but still leaning towards sysfs. The use case that >> needs this is device-dax because we otherwise silently do this behind >> the application's back on filesystem-dax for fsync / msync. > > We may yet get file system support for flush from userspace (NOVA, for > example). So I don't think we should restrict ourselves to only > thinking about the device dax use case. > >> A device-dax ioctl would be straightforward, but 'deep flush' assumes >> that the device-dax instance is fronting persistent memory. There's >> nothing persistent memory specific about device-dax except that today >> only the nvdimm sub-system knows how to create them, but there's >> nothing that prevents other memory regions from being mapped this way. > > You're concerned that applications operating on device dax instances > that are not backed by pmem will try to issue a deep flush? Why would > they do that, and why can't you just return failure from the ioctl? > >> So I'd rather this persistent memory specific mechanism stay with the >> persistent memory specific portion of the interface rather than plumb >> persistent memory details out through the generic device-dax interface >> since we have no other intercept point like we do in the >> filesystem-dax case to hide this flush. > > Look at the block layer. You can issue an ioctl on a block device, and > if the generic block layer can handle it, it does. If not, it gets > passed down to lower layers until either it gets handled, or it bubbles > back up because nobody knew what to do with it. I think you can do the > same thing here, and that solves your layering violation. So this is where I started. I was going to follow the block layer. Except recently the block layer has been leaning away from ioctls and implementing support for syscalls directly. The same approach for device-dax fallocate() support got NAKd, so I opted for sysfs out of the gate. However, since there really is no analog for "deep flush" in the syscall namespace lets (*gag*) implement an ioctl for this.
On Thu, Apr 27, 2017 at 1:02 PM, Dan Williams <dan.j.williams@intel.com> wrote: > On Thu, Apr 27, 2017 at 12:40 PM, Jeff Moyer <jmoyer@redhat.com> wrote: >> Dan Williams <dan.j.williams@intel.com> writes: >> >>> On Thu, Apr 27, 2017 at 11:41 AM, Jeff Moyer <jmoyer@redhat.com> wrote: >>>> Dan Williams <dan.j.williams@intel.com> writes: >>>> >>>>>> The sentiment is that programs shouldn't have to grovel around in sysfs >>>>>> to do stuff related to an open file descriptor or mapping. I don't take >>>>>> issue with the name. I do worry that something like 'wpq_drain' may be >>>>>> too platform specific, though. The NVM Programming Model specification >>>>>> is going to call this "deep flush", so maybe that will give you >>>>>> some inspiration if you do want to change the name. >>>>> >>>>> I'll change to "deep_flush", and I quibble that this is related to a >>>>> single open file descriptor or mapping. It really is a "region flush" >>>>> for giving extra protection for global metadata, but the persistence >>>>> of individual fds or mappings is handled by ADR. I think an ioctl >>>>> might give the false impression that every time you flush a cacheline >>>>> to persistence you need to call the ioctl. >>>> >>>> fsync, for example, may affect more than one fd--all data in the drive >>>> write cache will be flushed. I don't see how this is so different. I >>>> think a sysfs file is awkward because it requires an application to >>>> chase down the correct file in the sysfs hierarchy. If the application >>>> already has an open fd or a mapping, it should be able to operate on >>>> that. >>> >>> I'm teetering, but still leaning towards sysfs. The use case that >>> needs this is device-dax because we otherwise silently do this behind >>> the application's back on filesystem-dax for fsync / msync. >> >> We may yet get file system support for flush from userspace (NOVA, for >> example). So I don't think we should restrict ourselves to only >> thinking about the device dax use case. >> >>> A device-dax ioctl would be straightforward, but 'deep flush' assumes >>> that the device-dax instance is fronting persistent memory. There's >>> nothing persistent memory specific about device-dax except that today >>> only the nvdimm sub-system knows how to create them, but there's >>> nothing that prevents other memory regions from being mapped this way. >> >> You're concerned that applications operating on device dax instances >> that are not backed by pmem will try to issue a deep flush? Why would >> they do that, and why can't you just return failure from the ioctl? >> >>> So I'd rather this persistent memory specific mechanism stay with the >>> persistent memory specific portion of the interface rather than plumb >>> persistent memory details out through the generic device-dax interface >>> since we have no other intercept point like we do in the >>> filesystem-dax case to hide this flush. >> >> Look at the block layer. You can issue an ioctl on a block device, and >> if the generic block layer can handle it, it does. If not, it gets >> passed down to lower layers until either it gets handled, or it bubbles >> back up because nobody knew what to do with it. I think you can do the >> same thing here, and that solves your layering violation. > > So this is where I started. I was going to follow the block layer. > Except recently the block layer has been leaning away from ioctls and > implementing support for syscalls directly. The same approach for > device-dax fallocate() support got NAKd, so I opted for sysfs out of > the gate. > > However, since there really is no analog for "deep flush" in the > syscall namespace lets (*gag*) implement an ioctl for this. So I think about it for 2 seconds and now I'm veering back to sysfs. We don't want applications calling this ioctl on filesystem-dax fds. I simply can't bring myself to do the work to pick a unique ioctl number that is known to be unique for the full filsystem and block-layer paths when we can put this interface right where it belongs in nvdimm specific sysfs.
diff --git a/drivers/nvdimm/region_devs.c b/drivers/nvdimm/region_devs.c index 24abceda986a..9c4dc8bc759a 100644 --- a/drivers/nvdimm/region_devs.c +++ b/drivers/nvdimm/region_devs.c @@ -255,6 +255,35 @@ static ssize_t size_show(struct device *dev, } static DEVICE_ATTR_RO(size); +static ssize_t flush_show(struct device *dev, + struct device_attribute *attr, char *buf) +{ + struct nd_region *nd_region = to_nd_region(dev); + + /* + * NOTE: in the nvdimm_has_flush() error case this attribute is + * not visible. + */ + return sprintf(buf, "%d\n", nvdimm_has_flush(nd_region)); +} + +static ssize_t flush_store(struct device *dev, struct device_attribute *attr, + const char *buf, size_t len) +{ + bool flush; + int rc = strtobool(buf, &flush); + struct nd_region *nd_region = to_nd_region(dev); + + if (rc) + return rc; + if (!flush) + return -EINVAL; + nvdimm_flush(nd_region); + + return len; +} +static DEVICE_ATTR_RW(flush); + static ssize_t mappings_show(struct device *dev, struct device_attribute *attr, char *buf) { @@ -474,6 +503,7 @@ static DEVICE_ATTR_RO(resource); static struct attribute *nd_region_attributes[] = { &dev_attr_size.attr, + &dev_attr_flush.attr, &dev_attr_nstype.attr, &dev_attr_mappings.attr, &dev_attr_btt_seed.attr, @@ -508,6 +538,17 @@ static umode_t region_visible(struct kobject *kobj, struct attribute *a, int n) if (!is_nd_pmem(dev) && a == &dev_attr_resource.attr) return 0; + if (a == &dev_attr_flush.attr) { + int has_flush = nvdimm_has_flush(nd_region); + + if (has_flush == 1) + return a->mode; + else if (has_flush == 0) + return 0444; + else + return 0; + } + if (a != &dev_attr_set_cookie.attr && a != &dev_attr_available_size.attr) return a->mode;
The nvdimm_flush() mechanism helps to reduce the impact of an ADR (asynchronous-dimm-refresh) failure. The ADR mechanism handles flushing platform WPQ (write-pending-queue) buffers when power is removed. The nvdimm_flush() mechanism performs that same function on-demand. When a pmem namespace is associated with a block device, an nvdimm_flush() is triggered with every block-layer REQ_FUA, or REQ_FLUSH request. These requests are typically associated with filesystem metadata updates. However, when a namespace is in device-dax mode, userspace (think database metadata) needs another path to perform the same flushing. In other words this is not required to make data persistent, but in the case of metadata it allows for a smaller failure domain in the unlikely event of an ADR failure. The new 'flush' attribute is visible when the individual DIMMs backing a given interleave-set are described by platform firmware. In ACPI terms this is "NVDIMM Region Mapping Structures" and associated "Flush Hint Address Structures". Reads return "1" if the region supports triggering WPQ flushes on all DIMMs. Reads return "0" the flush operation is a platform nop, and in that case the attribute is read-only. Cc: Jeff Moyer <jmoyer@redhat.com> Cc: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> --- Changes in v3: * Fixed up the permissions in the read-only case to 0444 instead of 0400 as is typical for read-only sysfs attributes. drivers/nvdimm/region_devs.c | 41 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+)