10:33 p.m.
On Tue, Feb 23, 2016 at 1:55 PM, Boaz Harrosh <boaz(a)plexistor.com> 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.