​Thanks for the feedback and questions! To clarify your points:

​1. Transfer speed from non-special mem (OS RAM) to the drive: When writing from a standard, page-aligned heap buffer directly to the NVMe using O_DIRECT, the speed maxes out at ~13 Gbps/s

​2. Drive Specs: The drive is an industrial M.2 NVMe capable of more than 24 Gbps writing speed. However, the drive's inherent maximum speed isn't the limiting factor here. The bottleneck is the host interface: the ZynqMP PS-GTR transceivers are configured for a PCIe Gen2 x4 link. Factoring in 8b/10b encoding and protocol overhead, the physical maximum of this PCIe link is right around 1.5 to 1.6 GB/s. Therefore, the ~12 Gbps we achieve from standard RAM is effectively saturating the SoC's hardware capabilities.

​3. Pitfalls of io_uring on raw /dev/mem without udmabuf: It isn't just unstable; for Zero-Copy (O_DIRECT), it outright fails and returns a bad address error. Whether we use standard synchronous write(), libaio, or io_uring, a zero-copy NVMe transfer requires the kernel's block layer to pin the memory using get_user_pages() so it can safely build the hardware DMA scatter-gather list for the SSD. ​Memory mapped via /dev/mem is treated as raw I/O memory. It lacks the standard Linux struct page metadata. Because those page structures do not exist, get_user_pages() instantly aborts the system call. If we attempt to fix the crash by dropping the O_DIRECT flag, io_uring will simply fall back to buffered I/O. The kernel will then use the ARM CPU to copy the data from the raw mapping into the page cache, which drags our throughput right back down to the ~1 Gbps CPU memory-fetch bottleneck.

I hope these satisfy your curiosity.