COMMUNICATION OF DATA RELOCATION INFORMATION BY STORAGE DEVICE TO HOST TO IMPROVE SYSTEM PERFORMANCE

An apparatus comprises a controller comprising an interface comprising circuitry to communicate with a host computing device; and a relocation manager comprising circuitry, the relocation manager to provide, for the host computing device, an identification of a plurality of data blocks to be relocated within a non-volatile memory; and relocate at least a subset of the plurality of data blocks in accordance with a directive provided by the host computing device in response to the identification of the plurality of data blocks to be relocated.

BACKGROUND

A computer system may include one or more central processing units (CPUs) which may communicate with one or more storage devices. A CPU may include a processor to execute an operating system and/or other software applications that utilize a storage device coupled to the CPU. The software applications may write data to and read data from the storage device.

DETAILED DESCRIPTION

Although the drawings depict particular computer systems, the concepts of various embodiments are applicable to any suitable integrated circuits and other logic devices. Examples of devices in which teachings of the present disclosure may be used include desktop computer systems, server computer systems, storage systems, handheld devices, tablets, other thin notebooks, systems on a chip (SOC) devices, and embedded applications. Some examples of handheld devices include cellular phones, digital cameras, media players, personal digital assistants (PDAs), and handheld PCs. Embedded applications may include, e.g., a microcontroller, a digital signal processor (DSP), an SOC, a network computer (NetPC), a set-top box, a network hub, a wide area network (WAN) switch, or any other system that can perform the functions and operations taught below. Various embodiments of the present disclosure may be used in any suitable computing environment, such as a personal computing device, a server, a mainframe, a cloud computing service provider infrastructure, a datacenter, a communications service provider infrastructure (e.g., one or more portions of an Evolved Packet Core), or other environment comprising a group of computing devices.

FIG. 1illustrates a block diagram of a computer system100in which relocation information is communicated by a cache storage device106to a host (e.g., central processing unit (CPU)102) in accordance with certain embodiments. System100includes a CPU102coupled to a cache storage device106, a system memory device107, and a storage device110. During operation, data may be transferred between the CPU102and one or more of cache storage device106, system memory device107, and storage device110. In some instances, data may be transferred directly between two or more of cache storage device106, system memory device107, and storage device110. In various embodiments, particular data operations (e.g., erase, program, and read operations) or other communications involving the cache storage device106, system memory device107, or storage device110may be managed by one or more of an operating system (e.g., via file system115) or other software application (e.g., cache controller112) executed by processor108.

Caching is a technique to provide performance and cost benefits to end-users. For example, a system memory (e.g., dynamic random access memory (DRAM)) may be used to cache disk data. Alternatively, a fast storage device (e.g., a solid state drive (SSD) or a storage device such as a dual in-line memory module (DIMM) that comprises 3D crosspoint memory) may be used to cache data of slower storage devices (e.g., hard disk drives (HDDs)). When data that is not currently cached by the host computing device is requested by an application executed by the host, the data may be retrieved from the slower storage device and then stored in memory that may be accessed more easily by the host. For example, data retrieved from the slower storage device (e.g., a hard disk drive (HDD)) may be cached by storing the retrieved data in a cache storage device (e.g., SSD), a system memory device (e.g., DRAM), and/or one or more lower level caches of the CPU. After the data is cached, the data may be retrieved from one of the caches rather than the slower storage device, thus reducing the amount of latency for data accesses by the host.

Many storage devices (e.g., SSDs comprising NAND non-volatile memory) include an indirection structure for data in which logical block addresses (LBAs) used by the host are mapped to physical addresses of the storage device. The storage device may relocate physical data within the storage device in the background (e.g., independent of a specific command to do so from the host) using an operation known as “defrag” (which is shorthand for “defragmentation”) This process helps maintain good write performance, while satisfying various media-management constraints. A defrag operation moves multiple blocks of valid source data in a source band to a destination band, where a data block may refer to any suitable grouping of data. Background relocation of data blocks can be triggered due to numerous reasons, such as data invalidity levels, background data refresh, read disturb, NAND errors, preemptive error handling, or other reasons. Since defrag operations introduce additional reads and writes internally on the storage drive, they increase read and write amplification and reduce the storage drive's write-performance and endurance.

In configurations in which a storage device is used as a cache, relocation within the storage device is wasteful when the data being moved is stale within the cache or is about to be evicted from the cache. In configurations in which the storage device is used as the backing store and faster memory (such as DRAM, 3D crosspoint memory (e.g., 3D XPoint™), or other byte accessible non-volatile memory such as magnetoresistive random-access memory (MRAM)) is used as the caching media, the defrag operations on the storage device provide an opportunity to eliminate a media-read operation to perform a prefetch or a cacheline-insert, as the storage device needs to perform a read operation anyways as part of the defrag operation, and the same read operation can proactively provide the data for storage in the caching media (whether indirectly to the caching media through a cache controller or directly to the caching media via a peer to peer communication) for cache-insertion without requiring a separate data read operation.

Storage devices such as SSDs may also benefit from a “trim” or similar operation that advise the storage device that data at specified LBAs is no longer needed. For example, when a user deletes a file, the operating system may send a trim command to a controller of the storage devil indicating the data blocks (e.g., LBA region) that can be erased when garbage collection takes place on the storage device. The storage device may then optimize defrag operations such that the data specified in the trim operation is not moved (as it is no longer valid). Many systems determine and issue trim commands, but there may be a time lag between the issuance of the trim commands and associated defrag operations. For example, a system may issue trim commands nightly to one or more storage devices. However, defrag operations performed by the storage devices during the day may not be able to utilize associated trim operations to minimize data movement.

Various embodiments of the present disclosure boost storage device performance and endurance by allowing the storage device (e.g., SSD) to send relocation information to the host. In some embodiments, this communication is accomplished through Non-Volatile Memory Express (NVMe) Asynchronous Event Request-Notification or similar commands. The NVM Express revision 1.3 and prior revisions define a register level interface for host software to communicate with a non-volatile memory subsystem over PCI Express (NVMe™ over PCIe™). The NVMe™ over Fabrics specification defines a protocol interface and related extensions to the NVMe interface that enable operation over other interconnects (e.g., Ethernet, InfiniBand™, Fibre Channel). The NVMe over Fabrics specification has an NVMe Transport binding for each NVMe Transport (either within that specification or by reference). The NVMe specifications may be obtained at https://nvmexpress.org/resources/specifications/.

Depending on the data being moved and the cache policy dictating whether to keep, evict, or prefetch the data, caching logic can trim the blocks prior to relocation or opportunistically cache the blocks on relocation reads. In some embodiments, file systems may also use such notifications to issue trim commands with fine time-granularity. Various embodiments may allow information about relocation of data to inform various I/O operations initiated by the host including cache lazy-writes, cache prefetches, host file deletions from recycle bins, and triggering of SSD trim operations. Providing defrag relocation information to a host can reduce SSD relocations during I/O busy periods, thus boosting performance and endurance while allowing opportunistic caching and prefetching during relocation reads. Various technical advantages of some embodiments may include eliminating relocation waste, accelerating prefetches, improving cache hit-rates (and hence system level performance), and reducing internal write-amplification (and thus write-performance and endurance).

FIG. 1illustrates an embodiment in which a cache storage device106caches data of another storage device110. While the cache storage device106may be any suitable storage device, in some embodiments, the cache storage device106is an SSD or a NVDIMM comprising byte addressable non-volatile memory such as 3D crosspoint, MRAM, or other type of byte accessible non-volatile memory. Cache controller112may manage the caching of data from storage device110on cache storage device106. The cache controller112and other components of system100will be described in greater detail below. Example operation of system100is described with reference toFIG. 2.

FIG. 2illustrates an example flow200for communicating relocation information from the cache storage device106to a host (e.g., CPU102) in accordance with certain embodiments. In this flow, the cache controller112operates on behalf of the CPU102to communicate with the cache storage device106, though in other embodiments the communications and operations depicted may be performed by any suitable components of system100.

The flow begins at202as the cache controller112registers with the cache storage device106to receive relocation information from the cache storage device106. The registration request may take any suitable format. In one embodiment in which the cache storage device106implements an NVMe interface, the registration request may comprise an Asynchronous Event Request command (which is part of the NVMe Admin Command Set) with an opcode of 0x0C, e.g., as defined in NVM Express Base Specification, Revision1.4a or other suitable NVMe specification (current or future). The event type of the command may be set to “Vendor Specific event.” In general, the Asynchronous Event Request command is transmitted by software of the host to the cache storage device106to enable the reporting of asynchronous events from a storage device controller118of the cache storage device106.

At204, a list of valid blocks in a relocation band are generated by the cache storage device106. This list may be generated responsive to the triggering of a relocation of data within the cache storage device106(e.g., as part of a defrag operation). The list includes an identification of the blocks that are to be moved during the relocation. The list may have any suitable format that specifies one or more blocks of data that are to be moved, such as identifiers of individual blocks, ranges of blocks, or other suitable identifiers. In one embodiment, the list may comprise a bitmap indicating which blocks are to be relocated. In various embodiments, the blocks may be identified in the list using any suitable designations, such as LBAs or indirection units (IUs) (or representations thereof), where an IU may be a single LBA (e.g., 512 bytes or other size) or any suitable number of LBAs (e.g., 128 LBAs).

When the cache storage device106triggers a relocation of blocks, it notifies the cache controller112and then postpones the relocation until it receives a response including directives for the blocks. In some embodiments, if no response is received from the host within a timeout period, the cache storage device106relocates all of the blocks in the list.

At206, an event notification associated with the relocation of data blocks is sent from the cache storage device106to the cache controller112. In some embodiments, the event notification may indicate that a list of relocation blocks is available. As an example, when the NVMe interface is used, the storage device controller118of the cache storage device106may post a completion queue entry to an Admin Completion Queue when there is an asynchronous event (in this case a list of relocation blocks has been generated) to report to the host.

At208, the cache controller212requests the relocation blocks list from the cache storage device106. In one example, when the NVMe interface is used, this request may include a Get Log Page command for a vendor-specific log page that includes the list of relocation blocks. In other embodiments, the request may take any suitable format. At209, the relocation blocks list is provided to the cache controller112. In some embodiments, the event notification206may alternatively include the list of the relocation blocks (as opposed to a notification that an asynchronous event has occurred), such that cache controller112does not need to subsequently request the blocks. In various embodiments, the cache controller112may receive a relocation block list from the cache storage device106each time the cache storage device106triggers a relocation.

At210, the cache controller112processes the relocation blocks list. In a particular embodiment, the cache controller112may assign each block to be relocated to one of a set of buckets (e.g., by assigning a tag to each block or otherwise associating the assigned bucket with the block). In various embodiments, the buckets may be organized around the following guidelines. First, if a block has not been used (e.g., read by or written to by the host) recently, then it does not need to be included in the cache storage device106(as a cache is designed to store data that is expected to be used by the CPU in the near future). In various embodiments, whether a block has been recently used may be a binary decision based, e.g., on whether the block is included within a queue of recently used blocks or based on an indication of the time since the last usage of the block (e.g., this indication may change values over time and may be reset when the block is accessed). Second, if data is dirty (e.g., the data has been modified at the cache storage device106but has not been updated at the storage device110) then the data should be read from the cache storage device106and updated in the storage device110.

In the depicted embodiment ofFIG. 1, the cache controller112assigns blocks to four buckets: trim_bucket128, flush_trim_bucket130, relo_bucket132, and relo_flush_bucket134. In the embodiment depicted, these buckets are stored in system memory107, although in other embodiments the buckets may be stored in any suitable memory of the system100, such as a cache of the CPU102, a storage location dedicated to the buckets, or other suitable memory location. In one embodiment, during processing of the blocks at210, each block is assigned to one of these buckets.

If the block is not dirty and is not recently used, the block is assigned to the trim_bucket128for deletion from the cache storage device106. If the block is dirty and not recently used, the block is assigned to the flush_trim_bucket130for flushing to the storage device110and trimming from the cache storage device106. If the block is not dirty but has been used recently, the block is added to the relo_bucket132for the cache storage device106to relocate. Finally, if the block is dirty but has been used recently, the block is assigned to the relo_flush_bucket134so that the block can be relocated within cache storage device106as well as flushed to the storage device110at a suitable time (e.g., it may be written to the storage device110in the background in a lazy manner when bandwidth is available). The read performed at the cache storage device106as part of the data relocation process may be used opportunistically to obtain the data to be flushed to the storage device110.

After processing the blocks with respect to the buckets, the cache controller112instructs the cache storage device106with directives regarding the blocks marked for relocation. For example, at212a request is sent to the cache storage device106to trim the blocks in the trim_bucket128. As described earlier, a trim command indicates to cache storage device106that the blocks are not needed and thus may be excluded from the relocation.

At214, the cache controller112initiates a request to flush the blocks in the flush_trim_bucket130to the storage device110(this part of the flow may also include a corresponding read command from the host to the cache storage device106to obtain the data to be flushed to the storage device110). In addition, at216a request is sent to the cache storage device106to trim the blocks in the flush_trim_bucket130.

At218, a request to relocate blocks in the relo_bucket132is sent to the cache storage device106.

At220a request to cache and relocate the blocks in relo_flush_bucket134is sent to the cache storage device. This request instructs the cache storage device106to relocate the blocks in the relo_flush_bucket134and to leave the read data corresponding to these blocks in a transfer buffer127so that they may be read by the host without having to initiate a standard read operation to read the blocks from their original or relocated location. For example, when the cache storage device106relocates data, it may first read the data from its present location into a transfer buffer127and then write the data from the transfer buffer127to its relocated destination. In various embodiments, the transfer buffer127may comprise a type of memory (e.g., DRAM or SRAM) that allows for faster access than the type of memory (e.g., NAND flash or 3D Crosspoint) used to persistently store data by the cache storage device106. Thus, the cache storage device106may utilize the read that it performs during the relocation to make the data more easily available to the host via the transfer buffer127.

After (or concurrent with) providing directives for the blocks in the various buckets, the cache controller112instructs the cache storage device106that it may start block relocation of the remaining valid blocks (e.g., the blocks that were not removed from the list by the cache controller112via requests212and216) at222.

As the cache storage device106relocates the blocks, it may loop through the blocks checking to see whether the blocks being relocated are in the relo_flush_bucket134. If a particular block is in this bucket, then it is cached in the transfer buffer127of the cache storage device106during the relocation process. If the transfer buffer is full, then a notification of such is sent to cache controller112at226. If the transfer buffer is not full yet after placement of a block in the transfer buffer, the loop continues and when an additional block assigned to the relo_flush_bucket134is encountered, this block may also be read into the transfer buffer as it is relocated, and so on until the transfer buffer is full. Once the cache controller112is notified that the buffer is full, it reads the blocks in the buffer at228and then flushes the read blocks to the storage device110at230. If the buffer is not full, but the relocation operation has completed, the cache storage device106may notify the cache controller of such, and the cache controller112may read any remaining blocks in the transfer buffer and flush these to the storage device110.

In another embodiment, instead of reading the blocks of the relo_flush_bucket134from the transfer buffer127after relocation read operations, the cache controller112may issue a read and relocation request (which in one embodiment could be included in a single command, such as an NVMe vendor-specific command) to the cache storage device106to perform a standard read operation on the blocks of the relo_ flush_bucket134and to instruct the cache storage device106to relocate the blocks in the relo_flush_bucket134. In any event, once the data read is available, the cache controller112may flush the data to the storage device110.

The flow described inFIG. 2is merely representative of operations that may occur in particular embodiments. Operations may be performed in any suitable order without departing from the scope of particular embodiments. In other embodiments, additional operations may be performed in the flow. Some of the operations illustrated inFIG. 2may be repeated, combined, modified, or deleted where appropriate. For example, any one or more of212,216,218,220, and222may be combined within a single command sent from the cache controller112to the cache storage device106(which in one embodiment could be a NVMe vendor-specific command). As another example,212and216may be included within the same trim command and218,220, and222may be combined in another command (which in one embodiment could be a NVMe vendor-specific command). In other embodiments, a single command from the cache controller112may specify the blocks that are not to be relocated (and thus should be removed from the initial block relocation list received from the cache storage device106) or may specify the blocks that are to be relocated. In various embodiments, that same command (or a different command) may specify which blocks are to be cached during the relocation.

Returning again toFIG. 1, CPU102comprises a processor108, such as a microprocessor, an embedded processor, a digital signal processor (DSP), a network processor, a handheld processor, an application processor, a co-processor, an SOC, or other device to execute code (i.e., software instructions). Processor108, in the depicted embodiment, includes two processing elements (cores114A and114B), which may include asymmetric processing elements or symmetric processing elements. However, a processor may include any number of processing elements that may be symmetric or asymmetric.

In various embodiments, the processing elements may also include one or more arithmetic logic units (ALUs), floating point units (FPUs), caches, instruction pipelines, interrupt handling hardware, registers, or other hardware to facilitate the operations of the processing elements.

Application113may be executed by CPU102to perform any suitable operations. The application may be associated with application code that is executed by the processor108. The application code may be stored within storage device110, cache storage device106, and/or system memory107during various stages of operation of system100. The application may request data stored within storage device110, cache storage device106, and/or system memory107through file system115.

File system115makes stored data visible to an application113(e.g., by organizing storage in a hierarchical namespace). File system115may manage access to both the content of files and metadata about those files. File system115may receive system calls from the application113for data stored by computing system100. The file system115may be part of an operating system executed by CPU102. File system115may represent any suitable file system, such as a File Allocation Table (FAT), New Technology File System (NTFS), Resilient File System (ReFS), HFS+, a native Linux file system, or other suitable file system.

Cache controller112may receive data read and write requests and may determine how to complete these requests from or to the cache media (e.g., cache storage device106) and the backing-store media (e.g., storage device110). The cache controller may perform any other suitable functions, such as coordinating background operations (e.g., lazy writes) to keep the two media synchronized, managing mappings to data and metadata associated with the data, flushing data before dirty data is deleted from the cache storage device106, or managing prefetching of data into the cache storage device106.

In various embodiments, the cache controller112may utilize I/O controller109to communicate with cache storage device106or storage device110. For example, the cache controller112may send a request to the I/O controller109and the I/O controller109may transmit the request to the cache storage device106or storage device110. Similarly, the I/O controller109may receive communications from the cache storage device106or storage device110and provide the communications to the cache controller112.

I/O controller109is an integrated I/O controller that includes logic for communicating data between CPU102and I/O devices. In other embodiments, the I/O controller109may be on a different chip from the CPU102. I/O devices may refer to any suitable devices capable of transferring data to and/or receiving data from an electronic system, such as CPU102. For example, an I/O device may comprise an audio/video (A/V) device controller such as a graphics accelerator or audio controller; a data storage device controller, such as a flash memory device, magnetic storage disk, or optical storage disk controller; a wireless transceiver; a network processor; a network interface controller; or a controller for another input devices such as a monitor, printer, mouse, keyboard, or scanner; or other suitable device. In a particular embodiment, an I/O device may comprise a cache storage device106or storage device110that may be coupled to the CPU102through I/O controller109.

An I/O device may communicate with the I/O controller109of the CPU102using any suitable signaling protocol, such as peripheral component interconnect (PCI), PCI Express (PCIe), Universal Serial Bus (USB), Serial Attached SCSI (SAS), Serial ATA (SATA), Fibre Channel (FC), IEEE 802.3, IEEE 802.11, or other current or future signaling protocol. In particular embodiments, I/O controller109and an associated I/O device may communicate data and commands in accordance with a logical device interface specification such as NVMe (e.g., as described by one or more of the specifications available at www.nvmexpress.org/specifications/) or Advanced Host Controller Interface (AHCI) (e.g., as described by one or more AHCI specifications such as Serial ATA AHCI: Specification, Rev. 1.3.1 available at http://www.intel.com/content/www/us/en/io/serial-ata/serial-ata-ahci-spec-rev1-3-1.html). In various embodiments, I/O devices coupled to the I/O controller109may be located off-chip (e.g., not on the same chip as CPU102) or may be integrated on the same chip as the CPU102.

Memory controller111is an integrated memory controller that controls the flow of data going to and from one or more system memory devices107. Memory controller111may include logic operable to read from a system memory device107, write to a system memory device107, or to request other operations from a system memory device107. In various embodiments, memory controller111may receive write requests from cores114and/or I/O controller109and may provide data specified in these requests to a system memory device107for storage therein. Memory controller111may also read data from a system memory device107and provide the read data to I/O controller109or a core114. During operation, memory controller111may issue commands including one or more addresses of the system memory device107in order to read data from or write data to memory (or to perform other operations). In some embodiments, memory controller111may be implemented on the same chip as CPU102, whereas in other embodiments, memory controller111may be implemented on a different chip than that of CPU102. I/O controller109may perform similar operations with respect to one or more cache storage devices106or storage devices110.

A system memory device107may store any suitable data, such as data used by processor108to provide the functionality of computer system100. For example, data associated with programs that are executed or files accessed by cores114may be stored in system memory device107. Thus, a system memory device107may include a system memory that stores data and/or sequences of instructions that are executed or otherwise used by the cores114. In various embodiments, a system memory device107may store temporary data, persistent data (e.g., a user's files or instruction sequences) that remains stored even after power to the system memory device107is removed, or a combination thereof. A system memory device107may be dedicated to a particular CPU102or shared with other devices (e.g., one or more other processors or other devices) of computer system100.

In various embodiments, a system memory device107may include a memory comprising any number of memory arrays, a memory device controller, and other supporting logic (not shown). A memory array may include non-volatile memory and/or volatile memory. Non-volatile memory is a storage medium that does not require power to maintain the state of data stored by the medium. Nonlimiting examples of nonvolatile memory may include any or a combination of: solid state memory (such as planar or 3D NAND flash memory or NOR flash memory), 3D crosspoint memory, memory devices that use chalcogenide phase change material (e.g., chalcogenide glass), byte addressable nonvolatile memory devices, ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, polymer memory (e.g., ferroelectric polymer memory), ferroelectric transistor random access memory (Fe-TRAM) ovonic memory, nanowire memory, electrically erasable programmable read-only memory (EEPROM), other various types of non-volatile random access memories (RAMs), and magnetic storage memory. In some embodiments, 3D crosspoint memory may comprise a transistor-less stackable cross point architecture in which memory cells sit at the intersection of words lines and bit lines and are individually addressable and in which bit storage is based on a change in bulk resistance. Volatile memory is a storage medium that requires power to maintain the state of data stored by the medium. Examples of volatile memory may include various types of random access memory (RAM), such as DRAM or static random-access memory (SRAM). One particular type of DRAM that may be used in a memory array is synchronous dynamic random-access memory (SDRAM).

In particular embodiments, any portion of memory107(e.g., a portion of volatile memory) may comply with one or more portions of a standard promulgated by JEDEC for SDRAM memory, such as JESD79F for Double Data Rate (DDR) SDRAM, JESD79-2F for DDR2 SDRAM, JESD79-3F for DDR3 SDRAM, JESD79-4A for DDR4 SDRAM, or a Low Power DDR standard (e.g., LPDDR4) (these standards are available at www.jedec.org). Such standards (and similar standards) may be referred to as DDR-based standards.

A cache storage device106or storage device110may store any suitable data, such as data used by processor108to provide functionality of computer system100. For example, data associated with programs that are executed or files accessed by cores114A and114B may be stored in cache storage device106or storage device110. Thus, in some embodiments, a cache storage device106or storage device110may store data and/or sequences of instructions that are executed or otherwise used by the cores114A and114B. In various embodiments, a cache storage device106or storage device110may store persistent data (e.g., a user's files or software application code) that remains stored even after power to the cache storage device106or storage device110is removed. A cache storage device106or storage device110may be dedicated to CPU102or shared with other devices (e.g., another CPU or other device) of computer system100.

In the embodiment depicted, cache storage device106includes a storage device controller118and a memory116comprising four memory devices122A-D operable to store data, however, a cache storage device may include any suitable number of memory devices. A cache storage device106may include any number of memories116and each memory116may include any number of memory devices122(e.g.,122A-D). In a particular embodiment, a memory device122may be or comprise a semiconductor package with one or more memory chips123(e.g., memory chips123A-D). In the embodiment depicted, memory116includes memory devices122A-D (while specific references herein may be made to memory device122A, the other memory devices may have any suitable characteristics of memory device122A) and memory device controller126.

A memory device122A (e.g., each memory chip of the memory device) includes a plurality of memory cells that are each operable to store one or more bits. The cells of a memory device122A may be arranged in any suitable fashion, such as in rows (e.g., wordlines) and columns (e.g., bitlines), three dimensional structures, and/or other manner. In various embodiments, the cells may be logically grouped into banks, blocks, subblocks, planes, wordlines, pages, frames, bytes, or other suitable groups.

A memory device122A may include any of the volatile or non-volatile memories listed above or other suitable memory. In particular embodiments, memory device122A includes non-volatile memory, such as planar or 3D NAND flash memory. In particular embodiments, a memory device122A with non-volatile memory may comply with one or more standards for non-volatile memory promulgated by JEDEC, such as JESD218, JESD219, JESD220-1, JESD220C, JESD223C, JESD223-1, or other suitable existing or future standard (the JEDEC standards cited herein are available at www.jedec.org).

In various embodiments, a cache storage device106comprises NAND flash memory (herein a storage device comprising NAND flash memory is referred to as a NAND flash storage device). In some embodiments, cache storage device106may be a solid-state drive; a memory card; a Universal Serial Bus (USB) flash drive; or memory integrated within a device such as a smartphone, camera, media player, or other computing device. In general, storage devices with NAND flash memory are classified by the number of bits stored by each cell of the memory. For example, a single-level cell (SLC) memory has cells that each store one bit of data, a multi-level cell (MLC) memory has cells that each store two bits of data, a tri-level cell (TLC) memory has cells that each store three bits of data, a quad-level cell (QLC) memory has cells that each store four bits of data, and a penta-level cell (PLC) memory has cells that each store five bits of data, though some memories may utilize multiple encoding schemes (e.g., MLC and TLC) on the same array or on different arrays of the same device.

In a particular embodiment, a memory device122is a semiconductor package. In various embodiments, a semiconductor package may comprise a casing comprising one or more semiconductor dies (also referred to as chips), such as memory chips123A-D. A package may also comprise contact pins or leads used to connect to external circuits. However, a package is merely one example form a memory device122may take as a memory device may be any suitable arrangement of one or more memory arrays and associated logic in any suitable physical arrangement. For example, although a single physical package may include a single memory device122, multiple memory devices122could be resident on a single package or a memory device122could be spread across multiple packages.

A memory116may be embodied in one or more different physical mediums, such as a circuit board, die, disk drive, other medium, or any combination thereof (or combination with one or more packages). In a particular embodiment, memory116comprises a circuit board coupled to a plurality of memory devices122that each comprise a semiconductor package.

In various embodiments, storage device110may include any suitable characteristics described above with respect to cache storage device106. In some embodiments, the storage device110may comprise a disk driver that stores more data than cache storage device106, but is slower to access.

Cache storage device106, system memory device107, and storage device110may comprise any suitable types of memory and are not limited to a particular speed, technology, or form factor of memory in various embodiments. For example, a cache storage device106may be a disk drive (such as a solid-state drive), a flash drive, memory integrated with a computing device (e.g., memory integrated on a circuit board of the computing device), a memory module (e.g., a dual in-line memory module) that may be inserted in a memory socket, or other type of storage device. Similarly, system memory107or storage device110may have any suitable form factor. Moreover, computer system100may include multiple different types of storage devices.

System memory device107, cache storage device106, or storage device110may include any suitable interface to communicate with memory controller111or I/O controller109using any suitable communication protocol such as a DDR-based protocol, PCI, PCIe, USB, SAS, SATA, FC, System Management Bus (SMBus), or other suitable protocol. In some embodiments, a system memory device107, cache storage device106, or storage device110may include a communication interface to communicate with memory controller111or I/O controller109in accordance with any suitable logical device interface specification such as NVMe, AHCI, or other suitable specification. In particular embodiments, system memory device107, cache storage device106, or storage device110may comprise multiple communication interfaces that each communicate using a separate protocol with memory controller111and/or I/O controller109.

Storage device controller118may include logic to receive requests from CPU102(e.g., via an interface that communicates with memory controller111or I/O controller109), cause the requests to be carried out with respect to a memory116(or memory devices(s) and/or memory chip(s) thereof), and provide data associated with the requests to CPU102(e.g., via memory controller111or I/O controller109). Storage device controller118may also be operable to detect and/or correct errors encountered during memory operation. In an embodiment, controller118also tracks the number of times particular cells (or logical groupings of cells) have been written to in order to perform wear leveling and/or to detect when cells are nearing an estimated number of times they may be reliably written to. In performing wear leveling, the storage device controller118may evenly spread out write operations among blocks of the memory of a memory116such that particular blocks are not written to more than other blocks. In various embodiments, controller118may also monitor various characteristics of the cache storage device106such as the temperature or voltage and report associated statistics to the CPU102. Storage device controller118can be implemented on the same circuit board or device as a memory116or on a different circuit board, or device. For example, in some environments, storage device controller118may be a centralized storage controller that manages memory operations for multiple different memories116(which may each be of the same type of memory or may be of different types) of computer system100(and thus may provide storage device controller functionality described herein to any of the memories to which it is coupled).

In various embodiments, the cache storage device106also includes an address translation engine120. In the depicted embodiment, the address translation engine120is shown as part of the storage device controller118, although in various embodiments, the address translation engine120may be separate from the storage device controller118and communicably coupled to the storage device controller118. In various embodiments, the address translation engine120may be integrated on the same chip or package as the storage device controller118or on a different chip or package.

In various embodiments, address translation engine120may include logic to store and update a mapping between a logical address space (e.g., an address space visible to a host computing device coupled to the cache storage device106) and the physical address space of the memory116of the cache storage device106(which may or may not be exposed to the host computing device). The logical address space may expose a plurality of logical groups of data which are physically stored on corresponding physical groups of memory addressable through the physical address space of the cache storage device106. A physical address of the physical address space may comprise any suitable information identifying a physical memory location (e.g., a location within a memory array of a memory116) of the cache storage device106, such as an identifier of the memory116on which the physical memory location is located, an identifier of the memory device122A on which the physical memory location is located, one or more pages of the physical memory location, one or more subblocks of the physical memory location, one or more wordlines of the physical memory location, one or more bitlines of the physical memory location, or other suitable identifiers or encodings thereof.

In various embodiments, the cache storage device106also includes program control logic124which alone or in combination with a controller126of a memory device122is operable to control the programming sequence performed when data is written to a memory116, the read sequence performed when data is read from a memory116, or an erase sequence when data is erased from a memory116. In various embodiments, program control logic124may provide the various voltages (or information indicating which voltages should be provided) that are applied to one or more memory cells, wordlines, bitlines, and/or other portions of a memory array during the programming, reading, and/or erasing of data, perform error correction, and perform other suitable functions.

In various embodiments, the program control logic124may be integrated on the same chip as the storage device controller118or on a different chip. In the depicted embodiment, the program control logic124is shown as part of the storage device controller118, although in various embodiments, all or a portion of the program control logic124may be separate from the storage device controller118and communicably coupled to the storage device controller118. For example, all or a portion of the program control logic124may be located on the same package or chip as a memory116and/or memory devices122A-D.

Storage device controller118also includes a relocation manager125which may include logic to control operations associated with the relocation of data within memory116. For example, the relocation manager125may determine that a relocation operation is to be performed, generate a list of data blocks to be relocated, and interface with program control logic124to relocate data in accordance with directives received from the CPU102. In some embodiments, the relocation manager125may be integrated with the program control logic and/or address translation engine120.

Storage device controller118also includes a transfer buffer127comprising any suitable volatile or non-volatile memory to temporarily store data that is read from the memory116(e.g., during a relocation operation).

In some embodiments, all, or some of the elements of system100are resident on (or coupled to) the same circuit board (e.g., a motherboard). In various embodiments, any suitable partitioning between the elements may exist. For example, the elements depicted in CPU102may be located on a single die (i.e., on-chip) or package or any of the elements of CPU102may be located off-chip or off-package. Similarly, the elements depicted in cache storage device106may be located on a single chip or on multiple chips. In various embodiments, a cache storage device106and a host computing device (e.g., CPU102) may be located on the same circuit board or on the same device and in other embodiments the cache storage device106and the host computing device may be located on different circuit boards or devices.

The components of system100may be coupled together in any suitable manner. For example, a bus may couple any of the components together. A bus may include any suitable interconnect, such as a multi-drop bus, a mesh interconnect, a ring interconnect, a point-to-point interconnect, a serial interconnect, a parallel bus, a coherent (e.g. cache coherent) bus, a layered protocol architecture, a differential bus, or a Gunning transceiver logic (GTL) bus. In various embodiments, an integrated I/O subsystem includes point-to-point multiplexing logic between various components of system100, such as cores114, one or more memory controllers111, I/O controller109, integrated I/O devices, direct memory access (DMA) logic (not shown), etc. In various embodiments, components of computer system100may be coupled together through one or more networks comprising any number of intervening network nodes, such as routers, switches, or other computing devices. For example, a host computing device (e.g., CPU102) and the cache storage device106may be communicably coupled through a network.

Although not depicted, system100may use a battery and/or power supply outlet connector and associated system to receive power, a display to output data provided by CPU102, or a network interface allowing the CPU102to communicate over a network. In various embodiments, the battery, power supply outlet connector, display, and/or network interface may be communicatively coupled to CPU102. Other sources of power can be used such as renewable energy (e.g., solar power or motion based power).

FIG. 3illustrates a block diagram of a computer system300in which relocation information is communicated to a host (e.g., CPU302) by a storage device306in accordance with certain embodiments. In this embodiment, the storage device306is used as the backing store and the system memory307is used as the cache. In general, the components of the system300may have any suitable characteristics of the corresponding components of system100.

In this embodiment, instead of a caching controller (e.g.,112), the file system312includes caching logic326to implement caching functionality and relocation directives described herein. In various embodiments, caching logic326(or a subset thereof) may be integrated with the file system312, included in a driver executed by the CPU302, or otherwise included in an operating system executed by processor308. Similar to the cache controller112, the caching logic326may utilize a controller (e.g., I/O controller310) to communicate with the storage device306and system memory307.

In the embodiment depicted, the buckets used by the caching logic326are different from the buckets used when the storage device306is used as a cache storage device. While a trim_bucket328and a relo_bucket332are still used, the other two buckets have been replaced with a relo_cache_bucket334. In the embodiment depicted, these buckets are stored in system memory307, although in other embodiments the buckets may be stored in any suitable memory of the system300, such as a cache of the CPU302, a storage location dedicated to the buckets, or other suitable memory location.

FIG. 4illustrates an example flow400for communicating relocation information from a storage device306to caching logic326of a host (e.g., CPU302) in accordance with certain embodiments. Operations that are similar to operations of flow200may have any suitable characteristics of such operations described above.

The flow begins as the caching logic326of the file system312registers with the storage device306to receive relocation information from the storage device306at402. The registration request may take any suitable format. In one embodiment in which the storage device306implements an NVMe interface, the registration request may comprise an Asynchronous Event Request command as described earlier.

At404, a list of valid blocks in a relocation band are generated. This list may be generated responsive to the triggering of a relocation of data within the storage device306(e.g., as part of a defrag operation). The list includes an identification of the blocks that are to be moved during the relocation.

When the storage device306triggers a relocation of blocks, it notifies the caching logic326and then postpones the relocation until it receives a response including directives for the blocks from the caching logic326. In some embodiments, if no response is received from the host within a timeout period, the storage device306proceeds to relocate the blocks.

At406, an event notification associated with the relocation of data is sent from the storage device306to the caching logic326. In some embodiments, the event notification may indicate that a list of relocation blocks is available. As an example, when the NVMe interface is used, the controller318of the storage device306may post a completion queue entry to an Admin Completion Queue when there is an asynchronous event (in this case a list of relocation blocks has been generated) to report to the host.

At408, the caching logic326requests the relocation blocks list from the storage device306. In one example, when the NVMe interface is used, this request may include a Get Log Page command for a vendor-specific log page that includes the list of relocation blocks. In other embodiments, the request may take any suitable format. At409, the relocation blocks list is provided to the caching logic326. In some embodiments, the event notification406may alternatively include the list of the relocation blocks (as opposed to a notification that an asynchronous event has occurred), such that caching logic326does not need to subsequently request the blocks. After registering, the caching logic326may receive a relocation block list from the storage device306each time the storage device306triggers a relocation.

At410, the caching logic326processes the relocation blocks list. In a particular embodiment, the caching logic326may assign each block to be relocated to one of a set of buckets (e.g., by assigning a tag to each block or otherwise associating the assigned bucket with the block).

In the depicted embodiment ofFIG. 3, the caching logic326assigns blocks to three buckets: trim_bucket328, relo_bucket332, and relo_cache_bucket334. In one embodiment, during processing of the blocks at410, each block is assigned to one of these buckets.

If the block has been deleted in the file system312, but has not been trimmed on the storage device306(e.g., the CPU302has not yet notified the storage device306that the block has been deleted via a trim or other command), then the block is assigned to the trim_ bucket328for deletion from the storage device306.

If the block will be utilized by the CPU302in the near future, the block is assigned to the relo_cache_bucket334, to take advantage of the relocation read operation in order to cache the block in the system memory307. The determination of whether the block will be utilized by the CPU302in the near future may be based, e.g., on a prefetching policy of the CPU302. For example, the CPU302(e.g., via caching logic326) may maintain a list of blocks that are to be prefetched in anticipation of use of such blocks by the CPU302(before the blocks are explicitly requested by the CPU302). If the block being processed appears on this list (or is otherwise determined to be designated for prefetch), then it is placed in the relo_cache_bucket334.

If the block is not placed into either the trim_bucket328or the relo_cache_bucket334, then the block is placed in the relo_bucket332.

After processing the buckets, the caching logic326instructs the storage device306with directives regarding the blocks marked for relocation by the storage device306. For example, at412a request is sent to the storage device306to trim the blocks in the trim_bucket328. As described earlier, a trim command indicates to storage device306that the blocks are not needed and thus may be excluded from the relocation.

At414a request to cache and relocate the blocks in relo_cache_bucket334is sent to the storage device306. This request instructs the storage device306to relocate the blocks in the relo_cache_bucket134and to leave the read data corresponding to these blocks in a transfer buffer327of the storage device306so that they may be read by the CPU302without having to read them from their relocated locations (e.g., as described above with respect to flow200).

At416, a request to relocate blocks in the relo_bucket332is sent to the storage device306.

After (or concurrent with) providing directives for the blocks in the various buckets, the caching logic326then instructs the storage device306that it may start block relocation on the remaining valid blocks (e.g., the blocks that were not designated by the caching logic326as not needing relocation) at418.

As the storage device306relocates the blocks, it may loop through the blocks checking to see whether the data blocks being relocated are in the relo_cache_bucket334. If a particular block is in this bucket, then it is cached in the transfer buffer327of the storage device306during the relocation process. If the transfer buffer327is full, then a notification of such is sent to caching logic326at422. If the transfer buffer is not full yet, the loop continues and when an additional block that is assigned to the relo_cache_bucket334is encountered, this block may also be read into the transfer buffer, and so on until the transfer buffer is full. Once the caching logic326is notified that the transfer buffer327is full, the caching logic326reads the blocks in the buffer at424and then the read blocks are cached in the system memory307at426. If the buffer is not full, but the relocation operation has completed, the storage device306may notify the caching logic326of such, and the caching logic326may read any remaining blocks in the transfer buffer327and cache these blocks to the system memory307.

The flow described inFIG. 4is merely representative of operations that may occur in particular embodiments. Operations may be performed in any suitable order without departing from the scope of particular embodiments. In other embodiments, additional operations may be performed in the flow. Some of the operations illustrated inFIG. 4may be repeated, combined, modified, or deleted where appropriate. For example, any one or more of412,414,416, and418may be combined within a single command sent from the caching logic326to the storage device306(which in one embodiment could be an NVMe vendor-specific command). As another example,412may be a standard trim command and another command may combine the information of414,416, and418(e.g., in an NVMe vendor-specific command). In other embodiments, a single command from the caching logic326may identify the blocks that are not to be relocated (and thus should be removed from the block relocation list) or the command may identify the blocks that are to be relocated. In some embodiments, that same command (or a different command) may specify which blocks are to be cached during the relocation operation.

A design may go through various stages, from creation to simulation to fabrication. Data representing a design may represent the design in a number of manners. First, as is useful in simulations, the hardware may be represented using a hardware description language (HDL) or another functional description language. Additionally, a circuit level model with logic and/or transistor gates may be produced at some stages of the design process. Furthermore, most designs, at some stage, reach a level of data representing the physical placement of various devices in the hardware model. In the case where conventional semiconductor fabrication techniques are used, the data representing the hardware model may be the data specifying the presence or absence of various features on different mask layers for masks used to produce the integrated circuit. In some implementations, such data may be stored in a database file format such as Graphic Data System II (GDS II), Open Artwork System Interchange Standard (OASIS), or similar format.

In some implementations, software based hardware models, and HDL and other functional description language objects can include register transfer language (RTL) files, among other examples. Such objects can be machine-parsable such that a design tool can accept the HDL object (or model), parse the HDL object for attributes of the described hardware, and determine a physical circuit and/or on-chip layout from the object. The output of the design tool can be used to manufacture the physical device. For instance, a design tool can determine configurations of various hardware and/or firmware elements from the HDL object, such as bus widths, registers (including sizes and types), memory blocks, physical link paths, fabric topologies, among other attributes that would be implemented in order to realize the system modeled in the HDL object. Design tools can include tools for determining the topology and fabric configurations of system on chip (SoC) and other hardware device. In some instances, the HDL object can be used as the basis for developing models and design files that can be used by manufacturing equipment to manufacture the described hardware. Indeed, an HDL object itself can be provided as an input to manufacturing system software to cause the described hardware.

In any representation of the design, the data may be stored in any form of a machine readable medium. A memory or a magnetic or optical storage such as a disk may be the machine readable medium to store information transmitted via optical or electrical wave modulated or otherwise generated to transmit such information. When an electrical carrier wave indicating or carrying the code or design is transmitted, to the extent that copying, buffering, or re-transmission of the electrical signal is performed, a new copy is made. Thus, a communication provider or a network provider may store on a tangible, machine-readable medium, at least temporarily, an article, such as information encoded into a carrier wave, embodying techniques of embodiments of the present disclosure.

In various embodiments, a medium storing a representation of the design may be provided to a manufacturing system (e.g., a semiconductor manufacturing system capable of manufacturing an integrated circuit and/or related components). The design representation may instruct the system to manufacture a device capable of performing any combination of the functions described above. For example, the design representation may instruct the system regarding which components to manufacture, how the components should be coupled together, where the components should be placed on the device, and/or regarding other suitable specifications regarding the device to be manufactured.

Logic may be used to implement any of the flows described or functionality of the various components such as CPUs102and302, processors108and308, cores114A,114B,314A,314B, I/O controllers109and310, memory controllers111and311, cache storage device106, storage devices110and306, system memory devices107and307, cache controller112, file systems115and312, application113, caching logic326, buckets128,130,132,134,328,332,334, memories116and316, memory devices122and322, memory chips123, controllers126, storage device controllers118and318, address translation engines120and320, program control logic124and324, relocation managers125and325, transfer buffers127and327, subcomponents thereof, or other entity or component described herein. “Logic” may refer to hardware, firmware, software and/or combinations of each to perform one or more functions. In various embodiments, logic may include a microprocessor or other processing element operable to execute software instructions, discrete logic such as an application specific integrated circuit (ASIC), a programmed logic device such as a field programmable gate array (FPGA), a storage device containing instructions, combinations of logic devices (e.g., as would be found on a printed circuit board), or other suitable hardware and/or software. Logic may include one or more gates or other circuit components. In some embodiments, logic may also be fully embodied as software. Software may be embodied as a software package, code, instructions, instruction sets and/or data recorded on non-transitory computer readable storage medium. Firmware may be embodied as code, instructions or instruction sets and/or data that are hard-coded (e.g., nonvolatile) in storage devices.

Use of the phrase ‘to’ or ‘configured to,’ in one embodiment, refers to arranging, putting together, manufacturing, offering to sell, importing, and/or designing an apparatus, hardware, logic, or element to perform a designated or determined task. In this example, an apparatus or element thereof that is not operating is still ‘configured to’ perform a designated task if it is designed, coupled, and/or interconnected to perform said designated task. As a purely illustrative example, a logic gate may provide a0or a1during operation. But a logic gate ‘configured to’ provide an enable signal to a clock does not include every potential logic gate that may provide a1or0. Instead, the logic gate is one coupled in some manner that during operation the1or0output is to enable the clock. Note once again that use of the term ‘configured to’ does not require operation, but instead focus on the latent state of an apparatus, hardware, and/or element, where in the latent state the apparatus, hardware, and/or element is designed to perform a particular task when the apparatus, hardware, and/or element is operating.

Example 1 may include an apparatus comprising a controller comprising an interface comprising circuitry to communicate with a host computing device; and a relocation manager comprising circuitry, the relocation manager to provide, for the host computing device, an identification of a plurality of data blocks to be relocated within a non-volatile memory; and relocate at least a subset of the plurality of data blocks in accordance with a directive provided by the host computing device in response to the identification of the plurality of data blocks to be relocated.

Example 2 includes the subject matter of Example 1, wherein the directive provided by the host computing device includes an identification of a data block that does not need to be relocated.

Example 3 includes the subject matter of any of Examples 1-2, wherein the directive provided by the host computing device includes an identification of a data block to be cached in a transfer buffer for retrieval by the host computing device when the data block is read from the non-volatile memory during relocation of the block within the non-volatile memory.

Example 4 includes the subject matter of any of Examples 1-3, wherein the directive provided by the host computing device includes an identification of a data block to be relocated within the non-volatile memory.

Example 5 includes the subject matter of any of Examples 1-4, wherein the directive provided by the host computing device includes an identification of a data block that is to be transferred to the host computing device and relocated within the non-volatile memory.

Example 6 includes the subject matter of any of Examples 1-5, wherein the relocation manager is to provide the identification of the plurality of data blocks responsive to determining to perform a defragmentation operation on a portion of the non-volatile memory.

Example 7 includes the subject matter of any of Examples 1-6, wherein the relocation manager is to provide the identification of the plurality of data blocks to be relocated after receiving a registration request for relocation events from the host computing device.

Example 8 includes the subject matter of Example 7, wherein the registration request for relocation events is a Non-Volatile Memory Express (NVMe) Asynchronous Event Request command.

Example 9 includes the subject matter of any of Examples 1-8, further comprising the non-volatile memory.

Example 10 includes the subject matter of any of Examples 1-9, further comprising the host computing device, wherein the host computing device comprises a central processing unit (CPU).

Example 11 includes the subject matter of any of Examples 1-10, further comprising a battery communicatively coupled to a processor of the CPU, a display communicatively coupled to the processor, or a network interface communicatively coupled to the processor.

Example 12 includes a method comprising determining, by a storage device, to relocate a plurality of data blocks; providing, by the storage device to a host computing device, an identification of the plurality of data blocks to be relocated; and relocating, by the storage device, at least a subset of the plurality of data blocks in accordance with a directive provided by the host computing device in response to the identification of the plurality of data blocks to be relocated.

Example 13 includes the subject matter of Example 12, wherein the directive provided by the host computing device includes an identification of a data block that does not need to be relocated.

Example 14 includes the subject matter of any of Examples 12-13, wherein the directive provided by the host computing device includes an identification of a data block to be cached in a transfer buffer for retrieval by the host computing device when the data block is read from the non-volatile memory during relocation of the block.

Example 15 includes the subject matter of any of Examples 12-14, wherein the directive provided by the host computing device includes an identification of a data block to be relocated.

Example 16 includes the subject matter of any of Examples 12-15, wherein the directive provided by the host computing device includes an identification of a data block that is to be transferred to the host computing device and relocated.

Example 17 includes the subject matter of any of Examples 12-16, further comprising providing the identification of the plurality of data blocks responsive to determining to perform a defragmentation operation on a portion of the non-volatile memory.

Example 18 includes the subject matter of any of Examples 12-17, further comprising providing the identification of the plurality of data blocks to be relocated after receiving a registration request for relocation events from the host computing device.

Example 19 includes the subject matter of Example 18, wherein the registration request for relocation events is a Non-Volatile Memory Express (NVMe) Asynchronous Event Request command.

Example 20 comprises a system comprising means for providing, by a storage device to a host computing device, an identification of a plurality of data blocks to be relocated on the storage device; and means for relocating, by the storage device, at least a subset of the plurality of data blocks in accordance with a directive provided by the host computing device in response to the identification of the plurality of data blocks to be relocated.

Example 21 includes the subject matter of Example 20, wherein the directive provided by the host computing device includes an identification of a data block that does not need to be relocated.

Example 22 includes the subject matter of any of Examples 20-21, wherein the directive provided by the host computing device includes an identification of a data block to be cached in a transfer buffer for retrieval by the host computing device when the data block is read from the non-volatile memory during relocation of the block.

Example 23 includes the subject matter of any of Examples 20-22, wherein the directive provided by the host computing device includes an identification of a data block to be relocated.

Example 24 includes the subject matter of any of Examples 20-23, wherein the directive provided by the host computing device includes an identification of a data block that is to be transferred to the host computing device and relocated.

Example 25 includes the subject matter of any of Examples 20-24, further comprising providing the identification of the plurality of data blocks responsive to determining to perform a defragmentation operation on a portion of the non-volatile memory.

Example 26 includes the subject matter of any of Examples 20-25, further comprising providing the identification of the plurality of data blocks to be relocated after receiving a registration request for relocation events from the host computing device.

Example 27 includes the subject matter of Example 26, wherein the registration request for relocation events is a Non-Volatile Memory Express (NVMe) Asynchronous Event Request command.

Example 28 includes one or more non-transitory computer-readable media with code stored thereon, wherein the code is executable to cause a machine to provide, to a host computing device, an identification of a plurality of data blocks to be relocated on a storage device; and relocate at least a subset of the plurality of data blocks on the storage device in accordance with a directive provided by the host computing device in response to the identification of the plurality of data blocks to be relocated.

Example 29 includes the subject matter of Example 28, wherein the directive provided by the host computing device includes an identification of a data block that does not need to be relocated.

Example 30 includes the subject matter of any of Examples 28-29, wherein the directive provided by the host computing device includes an identification of a data block that should be cached in a transfer buffer for retrieval by the host computing device when the data block is read from a non-volatile memory during relocation of the block.

Example 31 includes the subject matter of any of Examples 28-30, wherein the directive provided by the host computing device includes an identification of a data block that should be relocated.

Example 32 includes the subject matter of any of Examples 28-31, wherein the directive provided by the host computing device includes an identification of a data block that is to be transferred to the host computing device and relocated.

Example 33 includes the subject matter of any of Examples 28-32, further comprising providing the identification of the plurality of data blocks responsive to determining to perform a defrag operation on a portion of a non-volatile memory.

Example 34 includes the subject matter of any of Examples 28-33, further comprising providing the identification of the plurality of data blocks to be relocated after receiving a registration request for relocation events from the host computing device.

Example 35 includes the subject matter of Example 34, wherein the registration request for relocation events is a Non-Volatile Memory Express (NVMe) Asynchronous Event Request command.