# uDMA: An Efficient User-Level DMA for NVMe SSDs +
## 5 Experiments and Results
### Micro Benchmark Test  
We used perf to generate several I/O requests for different data sizes: (1) 50,000 random I/O requests for data less than or equal to 4 KB, (2) 5000 random I/O requests for medium data with sizes of 4 KB to 128 KB, and (3) 5000 random I/O requests for big data sizes larger than 128 KB. The memory block size was also set to three cases. The blocks used for small IO requests were set to 32 MB, the pinned memory block size was 4 MB, and the memory block size used for data larger than 128 KB was set to 32 MB.  
Figure 5 shows the average response time of I/O requests for different data sizes. The \(x\)-axis and the \(y\)-axis represent the size of I/O requests and the average response time in seconds. It can be seen from Figure 5 that the performance of the NVMe SSD improved under all memory sizes tested, and the performance improvement was more evident under different data sizes. The main reason was that the algorithm's key idea was to allocate the pinned memory overhead to more requests and reduce the overhead of memory-related operations. It also optimized small data requests and used memory copy to effectively reduce the pinned memory overhead. The pinned memory pool was constructed in memory blocks for medium data to allocate the pinned memory overhead to multiple I/O requests. It could also be seen that under the same data size, with the increase of the program running time, the longer the memory usage time, the more pronounced the improvement effect of the algorithm. This was because with the increase of memory usage time, each memory block was used by more requests, and the pinned memory overhead of each memory block was allocated to more requests, which reduced the proportion of the overall memory operation-related overhead.  
Figure 6 shows the performance improvement effect of the algorithm under various test data sizes. It can be seen from the figure that under most data sizes, with the increase of the program running time, the improvement effect of the algorithm became more prominent.  
\begin{table}
\begin{tabular}{c c} \hline
**Environment** & **Configuration** \\ \hline CPU & Intel(R) Xeon(R) Gold 5115 CPU @ 2.40 GHz \\ Memory & 128 G \\ OS & CentOS Linux release 7.4.1708 (Core) \\ SPDK & 20.01 \\ GCC & 4.8.5 \\ NVMe Storage & Intel Optane 900P Series 280 GB NVMe SSD \\ \hline \end{tabular}
\end{table}
Table 1: The configuration of the experiment.  
The main reason was that more requests used the same memory block, and its pinned memory overhead was allocated to more requests accordingly.  
The second experiment verified the algorithm's efficiency under different program running times. The maximum sizes of selected memory test data were 64 KB and 128 KB. The test results are shown in Figure 7. It can be seen from the figure that with the increase in the running time of the simulation program, the effect of the algorithm was more prominent. The main reason was that with the increase in the program running time, the memory library in SPDK applied for and pinned memory every time and released memory after use, which introduced a significant overhead. The algorithm allocated the pinned memory overhead to more I/O requests, reducing the total memory operation overhead. The results showed the effectiveness of the algorithm. Allocating the allocated memory overhead to more requests could effectively improve performance.  
Figure 5: I/O response time under different data sizes.  
Figure 6: Performance improvement under different program running time.  
Figure 7: Influence of running time on Algorithm 1.