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