On 02/24/2016 06:09 AM, Ross Zwisler wrote:

On Tue, Feb 23, 2016 at 03:56:17PM -0800, Dan Williams wrote:

<>

MAP_PMEM_AWARE is interesting, but even in a perfect world it seems like a
partial solution - applications still need to call *sync to get the FS
metadata to be durable, and they have no reliable way of knowing which of
their actions will cause the metadata to be out of sync.

So there is the very simple answer:
	Just like today.

Today you need to call m/fsync after you have finished all modifications
and you want a persistent point. This of course will work. .I.E write
the application same as if the mount is not dax. But do set the flag
and switch to pmem_memcpy all over. BTW pmem_memcpy() will give you
10% gain on memory performance with fully-cached FS a swell.

I do not mind that. Just that with MAP_PMEM_AWARE the call to sync will
be fast and the page-faults much much faster. I'm a pragmatic person I'm saying
to application writers.
	Change nothing, have the same source code for both DAX and none DAX
	mode. Just switch to pmem_memcpy() / pmem_flush() everywhere and set
	the mmap flag, and you have 3x boost on your mmap performance.

Dave, is your objection to the MAP_SYNC idea a practical one about complexity
and time to get it implemented, or do you think it's is the wrong solution?

So you see with MAP_SYNC you are asking developers to write two versions of their
app, the later which does not call m/fsync.

[BTW MAP_SYNC is a *very bad* name because with it you are requiring the applications
 to switch to pmem_memcpy() and persistent stores everywhere. It might be very
 confusing and people might assume that the Kernel can magically guess every time
 an mmap pointer was modified, even after the page-fault.
 It should be called something like MAP_PMEM_SYNC
]

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

--
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>