# HMB-I/O: Fast Track for Handling Urgent I/Os in Nonvolatile Memory Express Solid-State Drives
## 2 Related Work  
### HMB of NVMe Interface  
As the NVMe interface was designed considering the SSD structure, it provides many features that enable SSDs to be exploited fully [10]. For example, it employs submission queues to send I/O requests to the SSD and completion queues to receive the responses from the SSD, where each of them can be scaled up to 64K, and each queue can contain entries up to 64K [3; 4; 11; 12; 13]. This scalable architecture allows SSDs to perform I/O requests in parallel without the unnecessary delay caused by waiting in a single queue.  
HMB is another exciting feature of the NVMe interface, which was first introduced in the NVMe 1.2 specifications. As it allows SSDs to use the host DRAM, SSDs can obtain more DRAM for caching address mapping tables or regular data. A DRAM-less SSD can provide performance comparable to that of a DRAM-containing SSD with reduced manufacturing cost by utilizing the HMB. This issue is still open, and the means of implementing this technology depend on SSD manufacturers [11; 14]. Using the HMB feature requires support from both the host and SSD. Modern operating systems such as Windows 10 and Linux and some DRAM-less SSDs support the HMB feature [15; 16; 17; 18; 19].  
Some steps are required to activate the HMB. Firstly, the host uses the host memory buffer preferred size (HMPRE) and host memory buffer minimum size (HMMIN) in the response of the NVMe Identify command to determine whether the NVMe SSD supports the HMB and to identify the HMB size the SSD needs. If the HMPRE is not zero, then the host supports the HMB. The HMB size that the SSD needs is equal to or greater than the HMMIN and equal to or less than the HMPRE. After checking both values, the host determines the HMB size and allocates the host DRAM accordingly. In recent Linux NVMe device drivers, the HMB size has been determined by the smaller of the HMPRE value and the device driver parameter. The HMB usually consists of multiple physically contiguous memory spaces; for example, 64 MB of HMB consists of 16 physically adjacent 4 MB areas. Then, the host issues NVMe set feature commands with 0 xd, which is the feature identifier for activating the HMB and sending some information related to the allocated spaces. Finally, if the SSD successfully responds to the request, the HMB can be accessed from the SSD. In Linux, all of these procedures are performed when initializing an NVMe SSD device.  
HMB has significant potential to improve the I/O performance of NVMe SSDs, but there has not been much research on this possibility yet. In [20,21], the authors used the HMB as a mapping table cache or data buffer and showed that it can mitigate the performance degradation of DRAM-less SSDs. [PERSON] et al. [22] proposed an architecture that uses the HMB as a data cache by modifying an NVMe command process and adding another DMA path between the system memory and HMB. They showed that the proposed architecture improved the I/O performance by 23% in the case of sequential writes compared to a device buffer architecture. [PERSON] et al. [8] presented an HMB-supported SSD emulator that enables easy integration and evaluation of I/O techniques for the HMB feature. Through implementation using their emulator, they also demonstrated that the I/O performance could be improved significantly when the HMB feature was used as a write buffer.