5:26 p.m.
On Tue, Feb 23, 2016 at 9:05 AM, Ross Zwisler
<ross.zwisler(a)linux.intel.com> wrote:
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.
MAP_PMEM_AWARE only declares self-awareness does not guarantee that
everyone else sharing the mapping is equally aware. A pmem-aware app
on such an architecture would be free to flush once and use
non-temporal stores going forward, but if the mapping is shared it
needs to flush all the time. Like I said before it needs to be
all-aware apps in a shared mapping or none, but it's moot because I
think something like MAP_SYNC is semantically much clearer.