9:05 a.m.
On Tue, Feb 23, 2016 at 08:56:57AM -0800, Dan Williams wrote:
On Tue, Feb 23, 2016 at 6:10 AM, Boaz Harrosh
<boaz(a)plexistor.com> wrote:
> On 02/23/2016 11:52 AM, Christoph Hellwig wrote:
[..]
> Please tell me what you find wrong with my approach?
Setting aside fs interactions you didn't respond to my note about
architectures where the pmem-aware app needs to flush caches due to
other non-pmem aware apps sharing the mapping. Non-temporal stores
guaranteeing persistence on their own is an architecture specific
feature. I don't see how we can have a generic support for mixed
MAP_PMEM_AWARE / unaware shared mappings when the architecture
dependency exists [1].
I think Christoph has already pointed out the roadmap. Get the
existing crop of DAX bugs squashed and then *maybe* look at something
like a MAP_SYNC to opt-out of userspace needing to call *sync.
[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.
I don't understand how this is an argument against Boaz's approach. If
non-temporal stores are essentially broken, they are broken for both the
kernel use case and for the userspace use case, and (if we want to support
these platforms, which I'm not sure we do) we would need to fall back to
writes + explicit flushes for both kernel space and userspace.
As long as each of userspace and kernel space are doing the right thing on
whatever platform we are on to get persistence for the writes that they do, I
think that everything works out essentially the same way.