On Tue, Feb 23, 2016 at 6:10 AM, Boaz Harrosh <boaz@xxxxxxxxxxxxx> 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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>