On Tue, Feb 23, 2016 at 9:05 AM, Ross Zwisler <ross.zwisler@xxxxxxxxxxxxxxx> 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@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. 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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>