# HMB-I/O: Fast Track for Handling Urgent I/Os in Nonvolatile Memory Express Solid-State Drives
## 5 Performance Evaluation  
We implemented the proposed HMB I/O scheme in the QEMU-based SSD emulator by referring to prior works [8; 28]. Our implementation includes HMB-related functions such as activating the HMB, dividing the HMB space for multiple purposes, and sharing the HMB with the host. We also added the HMB I/O handler and requester to the emulated SSD and Linux kernel, respectively. We conducted various experiments to verify the effectiveness of HMB I/O for providing QoS to urgent I/Os when an SSD has a bursty I/O load. Table 4 describes the experimental environments. The submission queue size of the emulated NVMe SSD was set to 16,384, and fio was used to generate heavy I/O workloads by issuing random read requests. In our experiment, the average number of I/O requests in each submission queue was about 14,890 when only fio was executed. To generate the urgent I/O requests that could be handled by HMB I/O, we used I/O workloads collected on a Nexus 5 Android smartphone [29]. The workloads consisted of I/O records that were collected at the block I/O layer and device driver of the smartphone when some applications or system functions such as sending and receiving calls were working (Table 5). To replay them in the block I/O layer, all I/O requests bypassed the caches and buffers of the host operating system and were directly delivered to the block I/O layer. Before executing the workloads in Table 5, we first executed fio for some duration to fill the submission queues with I/O requests sufficiently. Figure 6: HMB I/O data structures. Figure 7 shows the average latency of urgent I/O requests in four cases--when urgent I/O requests are processed via the original block I/O layer while Rio is not executed (_Idle_ (_original_)), when urgent I/O requests are processed by HMB I/O while Rio is not executed (_Idle_ (_HMB_ I/O)), when urgent I/O requests are processed by original block I/O layer while Rio is executed (_Busy_ (_original_)), and when urgent I/O requests are processed by HMB I/O while Rio is executed (_Busy_ (_HMB_ I/O)). When the SSD is busy with a heavy workload, the average latencies of urgent I/O requests reach 996.8 ms. However, by processing urgent I/O requests with HMB I/O, the average latency can be improved by 31.6-459.7 times. Above all, the latencies of urgent I/O requests are significantly stable when they are processed with HMB I/O. When Rio is executed simultaneously, the latencies of urgent I/O requests are from 0.11 to 2.48 ms if \begin{table}
\begin{tabular}{c c c} \hline \hline
**Processor** & \multicolumn{2}{c}{**6 Cores of Intel i7-8700**} \\ \hline \hline
**Main memory** & \multicolumn{2}{c}{16 GB} \\ \hline \multirow{5}{*}{**SSD**} & \multicolumn{2}{c}{**NVMe SSD Emulator Based on QEMU 2.9.0**} \\ \cline{2-3}  & - Total capacity: 36 GB & - Page size: 4 KB \\  & - Block size: 1 MB & - Submission queue size: 16,384 \\  & - Cell read: 40 μs & - Cell program: 800 μs \\  & - Register read: 60 μs & - Register write: 40 μs \\  & - Block erase: 300 μs & \\ \hline
**Operating system** & \multicolumn{2}{c}{Ubuntu 16.04 64 bits (Kernel 4.13.10)} \\ \hline \multirow{5}{*}{**I/O workloads**} & \multicolumn{2}{c}{**foo**} \\ \cline{2-3}  & - Random read & - I/O unit: 4 KB \\  & - Number of threads: 9 & - Direct I/O enabled \\  & - libaio used (depth: 16,384) & - Pre-running: 1 min \\  & \multicolumn{2}{c}{- Process priority as nice value: 19} \\ \cline{2-3}  & \multicolumn{2}{c}{**Micro-Benchmark for Replaying the Nexus5 Workloads**} \\ \cline{2-3}  & - Number of threads: 1 & - Direct I/O enabled \\  & - Process priority as nice value: \(-20\) & \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Experimental environments.