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