On Tue, Feb 23, 2016 at 1:55 PM, Boaz Harrosh <boaz@xxxxxxxxxxxxx> wrote: [..] > But seriously please explain the problem. I do not see one. > >> I think Christoph has already pointed out the roadmap. Get the >> existing crop of DAX bugs squashed > > Sure that's always true, I'm a stability freak through and through ask > the guys who work with me. I like to sleep at night ;-) > >> and then *maybe* look at something >> like a MAP_SYNC to opt-out of userspace needing to call *sync. >> > > MAP_SYNC Is another novelty, which as Dave showed will not be implemented > by such a legacy filesystem as xfs. any time soon. sync is needed not only > for memory stores. For me this is a supper set of what I proposed. because > again any file writes persistence is built of two parts durable data, and > durable meta-data. My flag says, app takes care of data, then the other part > can be done another way. For performance sake which is what I care about > the heavy lifting is done at the data path. the meta data is marginal. > If you want for completeness sake then fine have another flag. > > The new app written will need to do its new pmem_memcpy magic any way. > then we are saying "do we need to call fsync() or not?" > > I hate it that you postpone that to never because it would be nice for > philosophical sake to not have the app call sync at all. and all these > years suffer the performance penalty. Instead of putting in a 10 liners > patch today that has no risks, and yes forces new apps to keep the ugly > fsync() call, but have the targeted performance today instead of *maybe* never. > > my path is a nice intermediate progression to yours. Yours blocks my needs > indefinitely? > >> [1]: 10.4.6.2 Caching of Temporal vs. Non-Temporal Data >> "Some older CPU implementations (e.g., Pentium M) allowed addresses >> being written with a non-temporal store instruction to be updated >> in-place if the memory type was not WC and line was already in the >> cache." >> >> I wouldn't be surprised if other architectures had similar constraints. >> > > Perhaps you are looking at this from the wrong perspective. Pentium M > can do this because the two cores shared the same cache. But we are talking > about POSIX files semantics. Not CPU memory semantics. Some of our problems > go away. > > Or am I missing something out and I'm completely clueless. Please explain > slowly. > So I need to step back from the Pentium M example. It's already a red herring because, as Ross points out, prefetch concerns would require that strawman application to be doing cache flushes itself. Set that aside and sorry for that diversion. 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. 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. 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. -- 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>