[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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>