Re: [RFC 0/2] New MAP_PMEM_AWARE mmap flag

From: Boaz Harrosh <boaz@plexistor.com>
To: Ross Zwisler <ross.zwisler@linux.intel.com>,
	Dan Williams <dan.j.williams@intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	linux-nvdimm <linux-nvdimm@ml01.01.org>,
	Dave Chinner <david@fromorbit.com>,
	Oleg Nesterov <oleg@redhat.com>,
	Christoph Hellwig <hch@infradead.org>,
	linux-mm <linux-mm@kvack.org>, Mel Gorman <mgorman@suse.de>,
	Johannes Weiner <hannes@cmpxchg.org>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [RFC 0/2] New MAP_PMEM_AWARE mmap flag
Date: Thu, 25 Feb 2016 09:44:36 +0200	[thread overview]
Message-ID: <56CEB0E4.8080305@plexistor.com> (raw)
In-Reply-To: <20160224040947.GA10313@linux.intel.com>

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>