| Message ID | 149703989611.20620.6907872165215640212.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:56, Dan Williams wrote: > Some platforms arrange for cpu caches to be flushed on power-fail. On > those platforms there is no requirement that the kernel track and flush > potentially dirty cache lines. Given that we still insert entries into > the radix for locking purposes this patch only disables the cache flush > loop, not the dirty tracking. > > Userspace can override the default cache setting via the block device > queue "write_cache" attribute in sysfs. > > 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> ... > - dax_flush(dax_dev, pgoff, kaddr, size); > + if (test_bit(QUEUE_FLAG_WC, &bdev->bd_queue->queue_flags)) > + dax_flush(dax_dev, pgoff, kaddr, size); IMHO the check belongs into dax_flush() similarly as blkdev_issue_flush() takes silently handles whether the flush is actually needed or not. Honza
On Wed, Jun 14, 2017 at 3:46 AM, Jan Kara <jack@suse.cz> wrote: > On Fri 09-06-17 13:24:56, Dan Williams wrote: >> Some platforms arrange for cpu caches to be flushed on power-fail. On >> those platforms there is no requirement that the kernel track and flush >> potentially dirty cache lines. Given that we still insert entries into >> the radix for locking purposes this patch only disables the cache flush >> loop, not the dirty tracking. >> >> Userspace can override the default cache setting via the block device >> queue "write_cache" attribute in sysfs. >> >> 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> > > ... > >> - dax_flush(dax_dev, pgoff, kaddr, size); >> + if (test_bit(QUEUE_FLAG_WC, &bdev->bd_queue->queue_flags)) >> + dax_flush(dax_dev, pgoff, kaddr, size); > > IMHO the check belongs into dax_flush() similarly as blkdev_issue_flush() > takes silently handles whether the flush is actually needed or not. Looks good, will do. -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
On Fri, Jun 09, 2017 at 01:24:56PM -0700, Dan Williams wrote: > Some platforms arrange for cpu caches to be flushed on power-fail. On > those platforms there is no requirement that the kernel track and flush > potentially dirty cache lines. Given that we still insert entries into > the radix for locking purposes this patch only disables the cache flush > loop, not the dirty tracking. > > Userspace can override the default cache setting via the block device > queue "write_cache" attribute in sysfs. NAK. Please stop using the block infrastructure for dax values. Have your own flag and sysfs file in the dax infrastructure and only propagate it to the block layer for the block devices using dax. -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
On Sun, Jun 18, 2017 at 1:45 AM, Christoph Hellwig <hch@lst.de> wrote: > On Fri, Jun 09, 2017 at 01:24:56PM -0700, Dan Williams wrote: >> Some platforms arrange for cpu caches to be flushed on power-fail. On >> those platforms there is no requirement that the kernel track and flush >> potentially dirty cache lines. Given that we still insert entries into >> the radix for locking purposes this patch only disables the cache flush >> loop, not the dirty tracking. >> >> Userspace can override the default cache setting via the block device >> queue "write_cache" attribute in sysfs. > > NAK. Please stop using the block infrastructure for dax values. Have > your own flag and sysfs file in the dax infrastructure and only propagate > it to the block layer for the block devices using dax. Ok, that makes sense. -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
diff --git a/fs/dax.c b/fs/dax.c index 6d8699feae2e..c3140343ff7e 100644 --- a/fs/dax.c +++ b/fs/dax.c @@ -783,7 +783,8 @@ static int dax_writeback_one(struct block_device *bdev, } dax_mapping_entry_mkclean(mapping, index, pfn_t_to_pfn(pfn)); - dax_flush(dax_dev, pgoff, kaddr, size); + if (test_bit(QUEUE_FLAG_WC, &bdev->bd_queue->queue_flags)) + 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 @@ -975,7 +976,8 @@ int __dax_zero_page_range(struct block_device *bdev, return rc; } memset(kaddr + offset, 0, size); - dax_flush(dax_dev, pgoff, kaddr + offset, size); + if (test_bit(QUEUE_FLAG_WC, &bdev->bd_queue->queue_flags)) + dax_flush(dax_dev, pgoff, kaddr + offset, size); dax_read_unlock(id); } return 0;
Some platforms arrange for cpu caches to be flushed on power-fail. On those platforms there is no requirement that the kernel track and flush potentially dirty cache lines. Given that we still insert entries into the radix for locking purposes this patch only disables the cache flush loop, not the dirty tracking. Userspace can override the default cache setting via the block device queue "write_cache" attribute in sysfs. 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 | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel