[PATCH v2 0/7] dax: I/O path enhancements

From: Ross Zwisler
Date: Thu Aug 13 2015 - 12:51:27 EST


The goal of this series is to enhance the DAX I/O path so that all operations
that store data (I/O writes, zeroing blocks, punching holes, etc.) properly
synchronize the stores to media using the PMEM API. This ensures that the data
DAX is writing is durable on media before the operation completes.

Patches 1-4 are a few random cleanups.

Changes from v1:
- Removed patches to PMEM for the "read flush" _DSM flag. These are different
enough that they deserve their own series, and they have a separate baseline
which is currently moving (Dan's memremap() series).
- Added clear_pmem() PMEM API to zero DAX memory and flush it in one call.
(Dave)
- Open coded flushing in arch_wb_cache_pmem() instead of adding a generic
clwb_flush_range(). This allowed me to avoid having extra memory barriers
and instead rely completely on arch_wmb_pmem() for ordering. (Dave)
- Moved the arch implementation of the PMEM API into it's own arch header
(Christoph).

Ross Zwisler (7):
brd: make rd_size static
pmem, x86: move x86 PMEM API to new pmem.h header
pmem: remove layer when calling arch_has_wmb_pmem()
pmem, x86: clean up conditional pmem includes
pmem: add wb_cache_pmem() and clear_pmem()
dax: update I/O path to do proper PMEM flushing
pmem, dax: have direct_access use __pmem annotation

Documentation/filesystems/Locking | 3 +-
MAINTAINERS | 1 +
arch/powerpc/sysdev/axonram.c | 7 ++-
arch/x86/include/asm/cacheflush.h | 71 ----------------------
arch/x86/include/asm/pmem.h | 123 ++++++++++++++++++++++++++++++++++++++
drivers/block/brd.c | 6 +-
drivers/nvdimm/pmem.c | 4 +-
drivers/s390/block/dcssblk.c | 10 ++--
fs/block_dev.c | 2 +-
fs/dax.c | 73 ++++++++++++++--------
include/linux/blkdev.h | 8 +--
include/linux/pmem.h | 66 ++++++++++++++++----
12 files changed, 247 insertions(+), 127 deletions(-)
create mode 100644 arch/x86/include/asm/pmem.h

--
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/