On 02/24/2016 12:33 AM, Dan Williams wrote: <> > > In general MAP_SYNC, makes more sense semantic sense in that the > filesystem knows that the application is not going to be calling *sync > and it avoids triggering flushes for cachelines we don't care about. > I'm not sure I understand what you meant by "avoids triggering flushes for cachelines we don't care about". But again MAP_SYNC is nice but too nice, and will never just be. And why does it need to be either/or why not a progression turds. [In fact our system already has MAP_SYNC.] And you are contradicting yourself because with MAP_SYNC an application still needs to do its magical pmem_memcpy() > Although if we had MAP_SYNC today we'd still be in the situation that > an app that fails to do its own cache flushes / bypass correctly gets > to keep the broken pieces. > Yes that is true today and was always true and will always be true, your point being? > The crux of the problem, in my opinion, is that we're asking for an "I > know what I'm doing" flag, and I expect that's an impossible statement > for a filesystem to trust generically. If you can get MAP_PMEM_AWARE > in, great, but I'm more and more of the opinion that the "I know what > I'm doing" interface should be something separate from today's trusted > filesystems. > I disagree. I'm not saying any "trust me I know what I'm doing" flag. the FS reveals nothing and trusts nothing. All I'm saying is that the libc library I'm using as the new pmem_memecpy() and I'm using that instead of the old memecpy(). So the FS does not need to wipe my face after I eat. Failing to do so just means a bug in the application that failed to actually move the proper data to the place it needs to move to. The FS did its contract by providing the exact blocks back as was written to pmem this time by the app using pmem_memecpy(). So an FS did not violate any trust, and nothing the app did can cause any break to the the shared filesystem except a bad thing to itself. This is true anyway and was not invented by this patch. Cheers 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>