On Mon, Nov 16, 2015 at 11:48 AM, Ross Zwisler <ross.zwisler@xxxxxxxxxxxxxxx> wrote: > On Mon, Nov 16, 2015 at 09:28:59AM -0800, Dan Williams wrote: >> On Mon, Nov 16, 2015 at 6:05 AM, Jan Kara <jack@xxxxxxx> wrote: >> > On Mon 16-11-15 14:37:14, Jan Kara wrote: [..] > Is there any reason why this wouldn't work or wouldn't be a good idea? We don't have numbers to support the claim that pcommit is so expensive as to need be deferred, especially if the upper layers are already taking the hit on doing the flushes. REQ_FLUSH, means flush your volatile write cache. Currently all I/O through the driver never hits a volatile cache so there's no need to tell the block layer that we have a volatile write cache, especially when you have the core mm taking responsibility for doing cache maintenance for dax-mmap ranges. We also don't have numbers on if/when wbinvd is a more performant solution. tl;dr Now that we have a baseline implementation can we please use data to make future arch decisions? _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
