On Tue, Feb 23, 2016 at 6:10 AM, Boaz Harrosh [off-list ref] 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.

--
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>