On Tue, Nov 3, 2015 at 3:04 PM, Dan Williams <dan.j.willi...@intel.com> wrote: > On Tue, Nov 3, 2015 at 12:20 PM, Dave Chinner <da...@fromorbit.com> wrote: >> On Mon, Nov 02, 2015 at 11:35:04PM -0800, Dan Williams wrote: >>> On Mon, Nov 2, 2015 at 4:32 PM, Dave Chinner <da...@fromorbit.com> wrote: > [..] >>> Only in the mmap path: >> >> which means blkdev_direct_IO() is now always going to go down the >> dax_do_io() path for any driver with a ->direct_access method rather >> than the direct IO path, regardless of whether DAX is enabled on the >> device or not. >> >> That really seems wrong to me - you've replace explicit "is DAX >> enabled" checks with "is DAX possible" checks, and so DAX paths are >> used regardless of whether DAX is enabled or not. And it's not >> obvious why this is done, nor is it now obvious how DAX interacts >> with the block device. >> >> This really seems like a step backwards to me. > > I think the reason it is not obvious is the original justification for > the bypass as stated in commit bbab37ddc20b "block: Add support for > DAX reads/writes to block devices" was: > > "instead of allocating a DIO and a BIO" > > It turns out it's faster and as far as I can tell semantically > equivalent to the __blockdev_direct_IO() path. The DAX mmap path in > comparison has plenty of sharp edges and semantic differences that > would be avoided by turning off DAX. > > I'm not opposed to also turning off dax_do_io() when S_DAX is clear, > but I don't currently see the point. At the very least I need to add > the above comments to the code, but do you still think opt-in DAX is a > backwards step?
I thought of one way dax_do_io() breaks current semantics, it defeats blktrace and i/o stat tracking. I'll restore the existing behavior that gates dax_do_io() on S_DAX. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
