[Hi Andy - care to properly line break after ~75 character, that makes ready the message a lot easier, thanks!] On Mon, Feb 22, 2016 at 08:05:44PM +0000, Rudoff, Andy wrote: > I think several things are getting mixed together in this discussion: > > First, one primary reason DAX exists is so that applications can access > persistence directly. Agreed. > Once mappings are set up, latency-sensitive apps get load/store access > and can flush stores themselves using instructions rather than kernel calls. Disagreed. That's not how the architecture has worked at any point since the humble ext2/XIP days. It might be a worthwhile goal in the long run, but it's never been part of the architecture as discussed on the Linux lists, and it's not trivially implementable. > Second, programming to load/store persistence is tricky, but the usual API > for programming to memory-mapped files will "just work" and we built on > that to avoid needlessly creating new permission & naming models. Agreed. > If you want to use msync() or fsync(), it will work, but may not perform as > well as using the instructions. And this is BS. Using msync or fsync might not perform as well as not actually using them, but without them you do not get persistence. If you use your pmem as a throw away cache that's fine, but for most people that is not the case. > The instructions give you very fine-grain flushing control, but the > downside is that the app must track what it changes at that fine > granularity. Both models work, but there's a trade-off. No, the cache flush model simply does not work without a lot of hard work to enable it first. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>