4:24 p.m.
Hi, Dave,
Dave Chinner <david(a)fromorbit.com> writes:
Well, let me clarify what I said a bit here, because I feel like
I'm
being unfairly blamed for putting data integrity as the highest
priority for DAX+pmem instead of falling in line and chanting
"Performance! Performance! Performance!" with everyone else.
It's totally fair. ;-)
Let me state this clearly: I'm not opposed to making
optimisations
that change the way applications and the kernel interact. I like the
idea of MAP_SYNC, but I see this sort of API/behaviour change as a
last resort when all else fails, not a "first and only" optimisation
option.
So, calling it "first and only" seems a bit unfair on your part. I
don't think anyone asking for a MAP_SYNC option doesn't also want other
applications to work well. That aside, this is where your opinion
differs from mine: I don't see MAP_SYNC as a last resort option. And
let me be clear, this /is/ an opinion. I have no hard facts to back it
up, precisely because we don't have any application we can use for a
comparison. But, it seems plausible to me that no matter how well you
optimize your msync implementation, it will still be more expensive than
an application that doesn't call msync at all. This obviously depends
on how the application is using the programming model, among other
things. I agree that we would need real data to back this up. However,
I don't see any reason to preclude such an implementation, or to leave
it as a last resort. I think it should be part of our planning process
if it's reasonably feasible.
The big issue we have right now is that we haven't made the
DAX/pmem
infrastructure work correctly and reliably for general use. Hence
adding new APIs to workaround cases where we haven't yet provided
correct behaviour, let alone optimised for performance is, quite
frankly, a clear case premature optimisation.
Again, I see the two things as separate issues. You need both.
Implementing MAP_SYNC doesn't mean we don't have to solve the bigger
issue of making existing applications work safely.
Cheers,
Jeff