On Tue, Feb 23, 2016 at 9:05 AM, Ross Zwisler
[off-list ref] wrote:

On Tue, Feb 23, 2016 at 08:56:57AM -0800, Dan Williams wrote:

quoted

On Tue, Feb 23, 2016 at 6:10 AM, Boaz Harrosh [off-list ref] wrote:

quoted

On 02/23/2016 11:52 AM, Christoph Hellwig wrote:

[..]

quoted

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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>