386
The mmap(2) man page in the Linux Programmer’s manual describes the MAP_SYNC
flag as follows:
MAP_SYNC (since Linux 4.15)
This flag is available only with the MAP_SHARED_VALIDATE mapping
type; mappings of type MAP_SHARED will silently ignore this flag. This flag
is supported only for files supporting DAX (direct mapping of persistent
memory). For other files, creating a mapping with this flag results in an
EOPNOTSUPP error.
Shared file mappings with this flag provide the guarantee that while some
memory is writably mapped in the address space of the process, it will be
visible in the same file at the same offset even after the system crashes or is
rebooted. In conjunction with the use of appropriate CPU instructions, this
provides users of such mappings with a more efficient way of making data
modifications persistent.
Summary
In this chapter, we presented some of the more advanced topics for persistent memory
including page size considerations on large memory systems, NUMA awareness and
how it affects application performance, how to use volume managers to create DAX file
systems that span multiple NUMA nodes, and the MAP_SYNC flag for mmap(). Additional
topics such as BIOS tuning were intentionally left out of this book as it is vendor and
product specific. Performance and benchmarking of persistent memory products are left
to external resources as there are too many tools – vdbench, sysbench, fio, etc. – and too
many options for each one, to cover in this book.
Chapter 19 advanCed topiCs
The mmap(2) man page in the Linux Programmer’s manual describes the MAP_SYNC
flag as follows:
MAP_SYNC (since Linux 4.15)
This flag is available only with the MAP_SHARED_VALIDATE mapping
type; mappings of type MAP_SHARED will silently ignore this flag. This flag
is supported only for files supporting DAX (direct mapping of persistent
memory). For other files, creating a mapping with this flag results in an
EOPNOTSUPP error.
Shared file mappings with this flag provide the guarantee that while some
memory is writably mapped in the address space of the process, it will be
visible in the same file at the same offset even after the system crashes or is
rebooted. In conjunction with the use of appropriate CPU instructions, this
provides users of such mappings with a more efficient way of making data
modifications persistent.
Summary
In this chapter, we presented some of the more advanced topics for persistent memory
including page size considerations on large memory systems, NUMA awareness and
how it affects application performance, how to use volume managers to create DAX file
systems that span multiple NUMA nodes, and the MAP_SYNC flag for mmap(). Additional
topics such as BIOS tuning were intentionally left out of this book as it is vendor and
product specific. Performance and benchmarking of persistent memory products are left
to external resources as there are too many tools – vdbench, sysbench, fio, etc. – and too
many options for each one, to cover in this book.
Chapter 19 advanCed topiCs
