# HMB-I/O: Fast Track for Handling Urgent I/Os in Nonvolatile Memory Express Solid-State Drives
## 3 I/O latency with High Workload  
As mentioned above, I/O requests originating from file systems are passed to SSD devices via software and hardware queues in the Linux block I/O layer and submission queues in the NVMe interface. If an I/O request leaves the hardware queue, the host can no longer control it. When I/O requests are added at any moment, they must wait in the submission queues, which adversely affects the processing of urgent I/O requests. In this section, we provide an experimental analysis of the number of I/O requests that are queued in the submission queue when the I/O workload is high and show how much this queueing can delay the processing of urgent I/O requests. In fact, it is difficult to know exactly how many I/O requests are waiting in the submission queue at any given time. Both the head and tail positions are required to determine the number of I/O requests in the submission queue, but the host manages only the tail, the next insertion point, and not the head, the next deletion point. The head information can be obtained by _SQ Head Pointer_, which is part of the completion queue entry, but it is updated only when the SSD device finishes I/O processing and inserts the entry into the completion queue. Due to this limitation of NVMe, the average number of entries in each submission queue is updated in our method whenever the host dequeues the completion queue entries. In this way, we measured the number of I/O requests enqueued in the submission queue in the environment summarized in Table 1. These experiments were performed for the three SSDs described in Table 2, and one of the widely used storage benchmark tools, fio, was employed for I/O workload generation [24]. We used libaio as an I/O engine for fio and set the depth that is the number of simultaneous I/O requests made to the SSD from one to 65,536 [25]. We also set the submission queue size of each SSD to 16,384, which is the maximum size supported. In each experiment, we used the O_DIRECT flag to remove the effects of the buffer and cache layer inside the host operating system [26]. We also ran fio on only one of several CPU cores to avoid interfering with other processes. The configuration for this experiment is summarized in Table 3a. Note that we repeated all experiments 10 times to make the results reliable. \begin{table}
\begin{tabular}{c c} \hline \hline
**Processor** & **Intel i7-8700 (12 Cores)** \\ \hline Main memory & 64 GB \\ \hline Main storage & Samsung 860 PRO 256 GB \\ \hline Operating system & Ubuntu 16.04 64 bits (kernel 4.13.10, installed in the main storage) \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Experimental environment. \begin{table}
\begin{tabular}{c c c} \hline \hline  & **SSD** & **Capacity (GB)** \\ \hline SSD-A & Samsung 970 PRO 512 GB & 512 \\ \hline SSD-B & Samsung 970 EVO + 500 GB & 500 \\ \hline SSD-C & WD 3D Black 500 GB & 500 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Target solid-state drives (SSDs) used. Submission queue size and the number of submission queues are all 16,384 and 12, respectively. \begin{table}
\begin{tabular}{c c} \hline \hline  & Fio \\ \cline{2-3} (a) & - Random read & - I/O unit: 4 KB \\  & - Number of threads: 1 & - Direct I/O enabled \\  & - libaio used (depth: 1–65,536) & \\ \hline \hline \end{tabular}
\begin{tabular}{c} \hline \hline  & Fio \\ \cline{2-3} (b) & - Random read & - I/O unit: 4 KB \\  & - Number of threads: 12 & - Direct I/O enabled \\  & - libaio used (depth: 1–20,000) & - Process priority (nice value): 19 \\ \hline \hline \multicolumn{3}{c}{Micro-benchmark tool} \\ \cline{2-3} \multicolumn{2}{c}{- Read from offset 0} & - I/O unit and size: 512 B \\ \multicolumn{2}{c}{- Number of threads: 1} & - Direct I/O enabled \\ \multicolumn{2}{c}{- Process priority (nice value): \(-\)20} \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Configuration for generating I/O workloads to (a) count the number of I/O requests enqueued in the submission queue and (b) measure I/O delays caused by pending I/O requests in the submission queue.