| Message ID | 149703985873.20620.14408850278717601623.stgit@dwillia2-desk3.amr.corp.intel.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | Mike Snitzer |
| Headers | show |
On Fri 09-06-17 13:24:18, Dan Williams wrote: > Filesystem-DAX flushes caches whenever it writes to the address returned > through dax_direct_access() and when writing back dirty radix entries. > That flushing is only required in the pmem case, so the dax_flush() > helper skips cache management work when the underlying driver does not > specify a flush method. > > We still do all the dirty tracking since the radix entry will already be > there for locking purposes. However, the work to clean the entry will be > a nop for some dax drivers. > > Cc: Jan Kara <jack@suse.cz> > Cc: Jeff Moyer <jmoyer@redhat.com> > Cc: Christoph Hellwig <hch@lst.de> > Cc: Matthew Wilcox <mawilcox@microsoft.com> > Cc: Ross Zwisler <ross.zwisler@linux.intel.com> > Signed-off-by: Dan Williams <dan.j.williams@intel.com> Looks good to me. You can add: Reviewed-by: Jan Kara <jack@suse.cz> Honza > --- > fs/dax.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/dax.c b/fs/dax.c > index b459948de427..0933fc460ada 100644 > --- a/fs/dax.c > +++ b/fs/dax.c > @@ -784,7 +784,7 @@ static int dax_writeback_one(struct block_device *bdev, > } > > dax_mapping_entry_mkclean(mapping, index, pfn_t_to_pfn(pfn)); > - wb_cache_pmem(kaddr, size); > + dax_flush(dax_dev, pgoff, kaddr, size); > /* > * After we have flushed the cache, we can clear the dirty tag. There > * cannot be new dirty data in the pfn after the flush has completed as >
diff --git a/fs/dax.c b/fs/dax.c index b459948de427..0933fc460ada 100644 --- a/fs/dax.c +++ b/fs/dax.c @@ -784,7 +784,7 @@ static int dax_writeback_one(struct block_device *bdev, } dax_mapping_entry_mkclean(mapping, index, pfn_t_to_pfn(pfn)); - wb_cache_pmem(kaddr, size); + dax_flush(dax_dev, pgoff, kaddr, size); /* * After we have flushed the cache, we can clear the dirty tag. There * cannot be new dirty data in the pfn after the flush has completed as
Filesystem-DAX flushes caches whenever it writes to the address returned through dax_direct_access() and when writing back dirty radix entries. That flushing is only required in the pmem case, so the dax_flush() helper skips cache management work when the underlying driver does not specify a flush method. We still do all the dirty tracking since the radix entry will already be there for locking purposes. However, the work to clean the entry will be a nop for some dax drivers. Cc: Jan Kara <jack@suse.cz> Cc: Jeff Moyer <jmoyer@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Matthew Wilcox <mawilcox@microsoft.com> Cc: Ross Zwisler <ross.zwisler@linux.intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> --- fs/dax.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel