Skip to content

Commit 3e79f08

Browse files
kvaneeshmpe
authored andcommitted
libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier
Architectures like ppc64 provide persistent memory specific barriers that will ensure that all stores for which the modifications are written to persistent storage by preceding dcbfps and dcbstps instructions have updated persistent storage before any data access or data transfer caused by subsequent instructions is initiated. This is in addition to the ordering done by wmb() Update nvdimm core such that architecture can use barriers other than wmb to ensure all previous writes are architecturally visible for the platform buffer flush. Signed-off-by: Aneesh Kumar K.V <[email protected]> Reviewed-by: Dan Williams <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
1 parent d358042 commit 3e79f08

File tree

4 files changed

+29
-5
lines changed

4 files changed

+29
-5
lines changed

Documentation/memory-barriers.txt

+14
Original file line numberDiff line numberDiff line change
@@ -1935,6 +1935,20 @@ There are some more advanced barrier functions:
19351935
relaxed I/O accessors and the Documentation/DMA-API.txt file for more
19361936
information on consistent memory.
19371937

1938+
(*) pmem_wmb();
1939+
1940+
This is for use with persistent memory to ensure that stores for which
1941+
modifications are written to persistent storage reached a platform
1942+
durability domain.
1943+
1944+
For example, after a non-temporal write to pmem region, we use pmem_wmb()
1945+
to ensure that stores have reached a platform durability domain. This ensures
1946+
that stores have updated persistent storage before any data access or
1947+
data transfer caused by subsequent instructions is initiated. This is
1948+
in addition to the ordering done by wmb().
1949+
1950+
For load from persistent memory, existing read memory barriers are sufficient
1951+
to ensure read ordering.
19381952

19391953
===============================
19401954
IMPLICIT KERNEL MEMORY BARRIERS

drivers/md/dm-writecache.c

+1-1
Original file line numberDiff line numberDiff line change
@@ -536,7 +536,7 @@ static void ssd_commit_superblock(struct dm_writecache *wc)
536536
static void writecache_commit_flushed(struct dm_writecache *wc, bool wait_for_ios)
537537
{
538538
if (WC_MODE_PMEM(wc))
539-
wmb();
539+
pmem_wmb();
540540
else
541541
ssd_commit_flushed(wc, wait_for_ios);
542542
}

drivers/nvdimm/region_devs.c

+4-4
Original file line numberDiff line numberDiff line change
@@ -1206,13 +1206,13 @@ int generic_nvdimm_flush(struct nd_region *nd_region)
12061206
idx = this_cpu_add_return(flush_idx, hash_32(current->pid + idx, 8));
12071207

12081208
/*
1209-
* The first wmb() is needed to 'sfence' all previous writes
1210-
* such that they are architecturally visible for the platform
1211-
* buffer flush. Note that we've already arranged for pmem
1209+
* The pmem_wmb() is needed to 'sfence' all
1210+
* previous writes such that they are architecturally visible for
1211+
* the platform buffer flush. Note that we've already arranged for pmem
12121212
* writes to avoid the cache via memcpy_flushcache(). The final
12131213
* wmb() ensures ordering for the NVDIMM flush write.
12141214
*/
1215-
wmb();
1215+
pmem_wmb();
12161216
for (i = 0; i < nd_region->ndr_mappings; i++)
12171217
if (ndrd_get_flush_wpq(ndrd, i, 0))
12181218
writeq(1, ndrd_get_flush_wpq(ndrd, i, idx));

include/asm-generic/barrier.h

+10
Original file line numberDiff line numberDiff line change
@@ -257,5 +257,15 @@ do { \
257257
})
258258
#endif
259259

260+
/*
261+
* pmem_wmb() ensures that all stores for which the modification
262+
* are written to persistent storage by preceding instructions have
263+
* updated persistent storage before any data access or data transfer
264+
* caused by subsequent instructions is initiated.
265+
*/
266+
#ifndef pmem_wmb
267+
#define pmem_wmb() wmb()
268+
#endif
269+
260270
#endif /* !__ASSEMBLY__ */
261271
#endif /* __ASM_GENERIC_BARRIER_H */

0 commit comments

Comments
 (0)