On Fri, 18 Dec 2015 22:22:14 -0700 Ross Zwisler <ross.zwisler@xxxxxxxxxxxxxxx> wrote: > The function __arch_wb_cache_pmem() was already an internal implementation > detail of the x86 PMEM API, but this functionality needs to be exported as > part of the general PMEM API to handle the fsync/msync case for DAX mmaps. > > One thing worth noting is that we really do want this to be part of the > PMEM API as opposed to a stand-alone function like clflush_cache_range() > because of ordering restrictions. By having wb_cache_pmem() as part of the > PMEM API we can leave it unordered, call it multiple times to write back > large amounts of memory, and then order the multiple calls with a single > wmb_pmem(). > > @@ -138,7 +139,7 @@ static inline void arch_clear_pmem(void __pmem *addr, size_t size) > else > memset(vaddr, 0, size); > > - __arch_wb_cache_pmem(vaddr, size); > + arch_wb_cache_pmem(addr, size); > } > reject. I made this arch_wb_cache_pmem(vaddr, size); due to Dan's http://www.ozlabs.org/~akpm/mmots/broken-out/pmem-dax-clean-up-clear_pmem.patch -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
