On Sun, Feb 07, 2016 at 11:13:51AM -0800, Dan Williams wrote: > The proposal: make applications explicitly request DAX semantics with > a new MAP_DAX flag and fail if DAX is unavailable. Document that a > successful MAP_DAX request mandates that the application assumes > responsibility for cpu cache management. > Require that all applications that mmap the file agree on MAP_DAX. I think this proposal could run into issues with aliasing. For example, say you have two threads accessing the same region, and one wants to use DAX and the other wants to use the page cache. What happens? If we satisfy both requests, we end up with one user reading and writing to the page cache, while the other is reading and writing directly to the media. They can't see each other's changes, and you get data corruption. If we satisfy the request of whoever asked first, sort of lock the inode into that mode, and then return an error to the second thread because they are asking for the other mode, we have now introduced a new weird failure case where mmaps can randomly fail based on the behavior of other applications. I think this is where you were going with the last line quoted above, but I don't understand how it would work in an acceptable way. It seems like we have to have the decision about whether or not to use DAX made in the same way for all users of the inode so that we don't run into these types of conflicts. > This also solves > the future problem of DAX support on virtually tagged cache > architectures where it is difficult for the kernel to know what alias > addresses need flushing. > > [1]: https://github.com/pmem/nvml _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
