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

[Boaz Harrosh <boaz@plexistor.com>]

On 02/23/2016 11:52 AM, Christoph Hellwig wrote:
<>
> 
> 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.
> 

Hi Christoph

So is exactly my suggestion. My approach is *not* the we do not call
m/fsync to let the FS clean up.

In my model we still do that, only we eliminate the m/fsync slowness
and the all page faults overhead by being instructed by the application
that we do not need to track the data modified cachelines. Since the
application is telling us that it will do so.

In my model the job is split:
 App will take care of data persistence by instructing a MAP_PMEM_AWARE,
 and doing its own cl_flushing / movnt.
 Which is the heavy cost

 The FS will keep track of the Meta-Data persistence as it already does, via the
 call to m/fsync. Which is marginal performance compared to the above heavy
 IO.

Note that the FS is still free to move blocks around, as Dave said:
lockout pagefaultes, unmap from user space, let app fault again on a new
block. this will still work as before, already in COW we flush the old
block so there will be no persistence lost.

So this all thread started with my patches, and my patches do not say
"no m/fsync" they say, make this 3-8 times faster than today if the app
is participating in the heavy lifting.

Please tell me what you find wrong with my approach?

Thanks
Boaz

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