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