Messages in this thread | | | From | Dan Williams <> | Date | Wed, 6 Jun 2018 11:36:47 -0700 | Subject | Re: [PATCH v3 2/4] libnvdimm: unconditionally deep flush on *sync |
| |
On Wed, Jun 6, 2018 at 11:16 AM, Ross Zwisler <ross.zwisler@linux.intel.com> wrote: > On Wed, Jun 06, 2018 at 10:57:59AM -0700, Dan Williams wrote: >> On Wed, Jun 6, 2018 at 9:45 AM, Ross Zwisler >> <ross.zwisler@linux.intel.com> wrote: >> > Prior to this commit we would only do a "deep flush" (have nvdimm_flush() >> > write to each of the flush hints for a region) in response to an >> > msync/fsync/sync call if the nvdimm_has_cache() returned true at the time >> > we were setting up the request queue. This happens due to the write cache >> > value passed in to blk_queue_write_cache(), which then causes the block >> > layer to send down BIOs with REQ_FUA and REQ_PREFLUSH set. We do have a >> > "write_cache" sysfs entry for namespaces, i.e.: >> > >> > /sys/bus/nd/devices/pfn0.1/block/pmem0/dax/write_cache >> > >> > which can be used to control whether or not the kernel thinks a given >> > namespace has a write cache, but this didn't modify the deep flush behavior >> > that we set up when the driver was initialized. Instead, it only modified >> > whether or not DAX would flush CPU caches via dax_flush() in response to >> > *sync calls. >> > >> > Simplify this by making the *sync deep flush always happen, regardless of >> > the write cache setting of a namespace. The DAX CPU cache flushing will >> > still be controlled the write_cache setting of the namespace. >> > >> > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com> >> > Suggested-by: Dan Williams <dan.j.williams@intel.com> >> >> Looks, good. I believe we want this one and ["PATCH v3 4/4] libnvdimm: >> don't flush power-fail protected CPU caches" marked for -stable and >> tagged with: >> >> Fixes: 5fdf8e5ba566 ("libnvdimm: re-enable deep flush for pmem devices >> via fsync()") >> >> ...any concerns with that? > > Nope, sounds good. Can you fix that up when you apply, or would it be helpful > for me to send another revision with those tags?
I'll fix it up, thanks Ross.
| |