diff options
author | Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> | 2020-07-01 12:52:32 +0530 |
---|---|---|
committer | Michael Ellerman <mpe@ellerman.id.au> | 2020-07-16 13:00:22 +1000 |
commit | 3e79f082ebfc130360bcee23e4dd74729dcafdf4 (patch) | |
tree | 472f72323b983f91d8e078b32544e197c6e4848d /Documentation | |
parent | d358042793183a57094dac45a44116e1165ac593 (diff) | |
download | linux-3e79f082ebfc130360bcee23e4dd74729dcafdf4.tar.gz linux-3e79f082ebfc130360bcee23e4dd74729dcafdf4.tar.bz2 linux-3e79f082ebfc130360bcee23e4dd74729dcafdf4.zip |
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 <aneesh.kumar@linux.ibm.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200701072235.223558-5-aneesh.kumar@linux.ibm.com
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/memory-barriers.txt | 14 |
1 files changed, 14 insertions, 0 deletions
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index eaabc3134294..ff07cd3b2f82 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -1935,6 +1935,20 @@ There are some more advanced barrier functions: relaxed I/O accessors and the Documentation/DMA-API.txt file for more information on consistent memory. + (*) pmem_wmb(); + + This is for use with persistent memory to ensure that stores for which + modifications are written to persistent storage reached a platform + durability domain. + + For example, after a non-temporal write to pmem region, we use pmem_wmb() + to ensure that stores have reached a platform durability domain. This ensures + that stores 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(). + + For load from persistent memory, existing read memory barriers are sufficient + to ensure read ordering. =============================== IMPLICIT KERNEL MEMORY BARRIERS |