diff --git a/man2/statx.2 b/man2/statx.2
index 20f3ec031..4a4d30251 100644
--- a/man2/statx.2
+++ b/man2/statx.2
@@ -464,27 +464,33 @@ against a cryptographic hash that covers the
 entire file (e.g., via a Merkle tree).
 .TP
 .BR STATX_ATTR_DAX (since Linux 5.8)
-The file is in the DAX (cpu direct access) state.  DAX state attempts to
+The file is in the DAX (cpu direct access) state.
+DAX state attempts to
 minimize software cache effects for both I/O and memory mappings of this file.
 It requires a file system which has been configured to support DAX.
 .PP
-DAX generally assumes all accesses are via cpu load / store instructions which
-can minimize overhead for small accesses, but may adversely affect cpu
-utilization for large transfers.
+DAX generally assumes all accesses are via CPU load / store instructions
+which can minimize overhead for small accesses,
+but may adversely affect CPU utilization for large transfers.
 .PP
 File I/O is done directly to/from user-space buffers and memory mapped I/O may
-be performed with direct memory mappings that bypass kernel page cache.
+be performed with direct memory mappings that bypass the kernel page cache.
 .PP
 While the DAX property tends to result in data being transferred synchronously,
-it does not give the same guarantees of O_SYNC where data and the necessary
-metadata are transferred together.
+it does not give the same guarantees as the
+.B O_SYNC
+flag (see
+.BR open (2)),
+where data and the necessary metadata are transferred together.
 .PP
-A DAX file may support being mapped with the MAP_SYNC flag, which enables a
+A DAX file may support being mapped with the
+.B MAP_SYNC
+flag, which enables a
 program to use CPU cache flush instructions to persist CPU store operations
 without an explicit
-.BR fsync(2).
+.BR fsync (2).
 See
-.BR mmap(2)
+.BR mmap (2)
 for more information.
 .SH RETURN VALUE
 On success, zero is returned.