Patent Description:
Some applications may depend on data that is large in size. If this data is not already stored in memory, the data may be read from storage devices. But accessing data from a single storage device may form a bottleneck, slowing down data access and the resulting computations.

A need remains to provide for low latency access to data.

<CIT> discloses: A data storage device may be configured to use multiple task queues to schedule tasks. The multiple task queues may be configured based on an architecture of the data storage device. In some implementations, the multiple task queues may be used to organize tasks received from an access device. In other implementations, the multiple task queues may be used to identify tasks, and identification of the tasks may be associated with an order of execution of the tasks.

Further developments of the invention are specified in the dependent claims. Embodiments of the disclosure include a system and a method. The system includes a storage device to store data and a load module to read the data from the storage device. A scheduler receives an input/output (I/O) request and deliver the I/O request to the load module based on a size of the I/O request.

The drawings described below are examples of how embodiments of the disclosure may be implemented, and are not intended to limit embodiments of the disclosure. Individual embodiments of the disclosure may include elements not shown in particular figures and/or may omit elements shown in particular figures. The drawings are intended to provide illustration and may not be to scale.

Reference will now be made in detail to embodiments of the disclosure, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth to enable a thorough understanding of the disclosure. It should be understood, however, that persons having ordinary skill in the art may practice the disclosure without these specific details.

For example, a first module could be termed a second module, and, similarly, a second module could be termed a first module, without departing from the scope of the disclosure.

The terminology used in the description of the disclosure herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used in the description of the disclosure, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. The components and features of the drawings are not necessarily drawn to scale.

Some applications, such as deep learning recommendation models (DLRMs), may rely on large amounts of data. DLRMs may rely on embedding tables, which may be terabytes in size. Transferring large amounts of data from a storage device to a memory for processing may take time. This issue may be exacerbated if multiple applications are attempting to process data stored on the storage device, as the storage device may have a bandwidth limit insufficient for all the data requested.

Embodiments of the disclosure address these concerns by introducing a system of storage devices. The storage devices may be, for example, Solid State Drives (SSDs). Data may be distributed across the storage devices, which may reduce the load on an individual storage device to provide all the requested data. A scheduler may schedule I/O requests into one or more queues based on the size of the data to be retrieved. An input/output (I/O) process manager may retrieve requests from the queues and may identify load modules to retrieve data from storage devices.

<FIG> shows a machine configured to support low latency access to storage devices in processing computations, according to embodiments of the disclosure. In <FIG>, machine <NUM>, which may also be termed a host or a system, may include processor <NUM>, memory <NUM>, and storage devices <NUM>-<NUM> and <NUM>-<NUM> (which may be referred to collectively as storage devices <NUM>). Processor <NUM> may be any variety of processor. (Processor <NUM>, along with the other components discussed below, are shown outside the machine for ease of illustration: embodiments of the disclosure may include these components within the machine. ) While <FIG> shows a single processor <NUM>, machine <NUM> may include any number of processors, each of which may be single core or multi-core processors, each of which may implement a Reduced Instruction Set Computer (RISC) architecture or a Complex Instruction Set Computer (CISC) architecture (among other possibilities), and may be mixed in any desired combination.

Processor <NUM> may be coupled to memory <NUM>. Memory <NUM> may be any variety of memory, such as flash memory, Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Persistent Random Access Memory, Ferroelectric Random Access Memory (FRAM), or Non-Volatile Random Access Memory (NVRAM), such as Magnetoresistive Random Access Memory (MRAM) etc. Memory <NUM> may be a volatile or non-volatile memory, as desired. Memory <NUM> may also be any desired combination of different memory types, and may be managed by memory controller <NUM>. Memory <NUM> may be used to store data that may be termed "short-term": that is, data not expected to be stored for extended periods of time. Examples of short-term data may include temporary files, data being used locally by applications (which may have been copied from other storage locations), and the like.

Processor <NUM> and memory <NUM> may also support an operating system under which various applications may be running. These applications may issue requests (which may also be termed commands) to read data from or write data to either memory <NUM>. When storage device <NUM> is used to support applications reading or writing data via some sort of file system, storage devices <NUM> may be accessed using device driver <NUM>. While <FIG> shows two storage devices <NUM>, there may be any number (one or more) of storage devices in machine <NUM>. Storage devices <NUM> may each support any desired protocol or protocols, including, for example, the Non-Volatile Memory Express (NVMe) protocol. Different storage devices <NUM> may support different protocols and/or interfaces.

While <FIG> uses the generic term "storage device", embodiments of the disclosure may include any storage device formats that may benefit from the use of computational storage units, examples of which may include hard disk drives and Solid State Drives (SSDs). Any reference to "SSD" below should be understood to include such other embodiments of the disclosure. Further, different types of storage devices may be mixed. For example, storage device <NUM>-<NUM> might be a hard disk drive, and storage device <NUM>-<NUM> might be an SSD.

Machine <NUM> may also include multi-process system <NUM> and computation system <NUM>. Multi-process system <NUM> may manage reading data from storage devices <NUM> based on input/output (I/O) requests received from applications running on processor <NUM> (or on processors on remote machines not shown in <FIG>). The I/O requests may request data from storage devices <NUM> that may be used in computation processes. That is, given a computation request, the data to be processed by the computation request may first be requested from storage devices <NUM> in an I/O request processed by multi-process system <NUM>. Multi-process system <NUM> may schedule reading data from storage devices <NUM> based on the size of the I/O request, in order to reduce the latency (the time required to complete the computation processes, including the time required to read the data and execute the appropriate commands on the data). Multi-process system <NUM> is discussed further with reference to <FIG> below.

Once the data is read by multi-process system <NUM>, computation system <NUM> may execute the computation process to process the data. Computation system <NUM> is discussed further with reference to <FIG> below.

As mentioned above, machine <NUM> may include multiple storage devices <NUM>. By including more than one storage device <NUM>, the data requested in an I/O request might be distributed across storage devices <NUM>. By distributing the data across storage devices <NUM>, read requests may be processed by each storage device <NUM>: if these read requests are processed in parallel, the requested data might be read faster than if all the data were stored on only one storage device <NUM>. But embodiments of the disclosure may include one storage device <NUM> (without the potential benefit of reading the data in parallel from multiple storage devices <NUM>).

While <FIG> shows machine <NUM> as including multi-process system <NUM> and computation system <NUM>, embodiments of the disclosure may have these components located elsewhere. For example, multi-process system <NUM> might be included as part of machine <NUM>, while computation system <NUM> might be part of another machine reached across a network. In fact, embodiments of the disclosure might separate storage devices <NUM>, multi-process system <NUM>, and computation system <NUM> each on separate machines <NUM>, connected via some network or communication path.

<FIG> shows details of the machine of <FIG>, according to embodiments of the disclosure. In <FIG>, typically, machine <NUM> includes one or more processors <NUM>, which may include memory controllers <NUM> and clocks <NUM>, which may be used to coordinate the operations of the components of the machine. Processors <NUM> may also be coupled to memories <NUM>, which may include random access memory (RAM), read-only memory (ROM), or other state preserving media, as examples. Processors <NUM> may also be coupled to storage devices <NUM>, and to network connector <NUM>, which may be, for example, an Ethernet connector or a wireless connector. Processors <NUM> may also be connected to buses <NUM>, to which may be attached user interfaces <NUM> and Input/Output (I/O) interface ports that may be managed using I/O engines <NUM>, among other components.

Before explaining the structure and operation of multi-process system <NUM> of <FIG>, it may be helpful to consider various requests that may be processed using machine <NUM> of <FIG>. An example application that may be running on processor <NUM> of <FIG> is a deep learning recommendation model (DLRM), which is an example of a machine learning algorithm. The DLRM application may have established a service level agreement (SLA) that may govern how long it should take to process a query. Put another way, the DLRM may expect a particular query to take a certain amount of time: if the query takes longer than that amount of time, the DLRM may wait longer than expected before it continue processing.

To execute the query, machine <NUM> of <FIG> may need to retrieve the data in question and then perform a computation process on that data. Both retrieving the data and processing the computations may take some amount of time.

If the query is relatively small (say, involving fewer than <NUM> data points), retrieving the data may be relatively fast, and the overall process of executing the query may satisfy the SLA. But if the query is relatively large (say, involving more than <NUM> data points), retrieving the data might take a long enough amount of time that the SLA might not be satisfied. Since the DLRM may have variable query sizes, relatively large queries might be expected to occur, and the process of retrieving the stored data might be larger than the time required to execute the computation process. Since it is not desirable for machine <NUM> of <FIG> to fail to satisfy the SLA, it is desirable to reduce the time required to retrieve the data from storage devices <NUM> of <FIG>: that is, to achieve a low latency for data retrieval.

<FIG> shows details of multi-process system <NUM> of <FIG>, according to embodiments of the disclosure. In <FIG>, multi-process system <NUM> may include I/O scheduler <NUM>, queues <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> (which may be referred to collectively as queues <NUM>), and I/O process/storage pool <NUM>.

I/O scheduler <NUM> may receive I/O requests from applications running on processor <NUM> of <FIG>. Such requests may identify the data to be read from storage devices <NUM>, for use in a computation request (to be processed by computation system <NUM> of <FIG>).

I/O scheduler <NUM> may determine the size of the I/O requests: that is, the amount of data to be read from storage devices <NUM> to be used in executing the computation process. Using the size of the I/O request, I/O scheduler <NUM> may select one of queues <NUM> in which to place the I/O request.

In <FIG>, three queues <NUM>-<NUM> through <NUM>-<NUM> are shown. Each queue <NUM> may be used to store I/O requests of varying sizes. For example, queue <NUM>-<NUM> might be used to store I/O requests to retrieve data (rows of an embedding table) no larger than, say, <NUM> vectors in size; queue <NUM>-<NUM> might be used to store I/O requests larger than, say, <NUM> vectors in size but no larger than, say, <NUM> vectors in size; and queue <NUM>-<NUM> might be used to store I/O requests larger than, say, <NUM> vectors in size. In this manner, I/O requests may be grouped based on approximately the amount of data to be retrieved, which may be representative of the amount of time needed to retrieve the data.

While <FIG> shows three queues <NUM>, embodiments of the disclosure may include any number (one or more) of queues <NUM>. For example, if priority queueing is used, embodiments of the disclosure might include one queue <NUM>. If priority queueing is used, I/O scheduler <NUM> may determine a priority for the I/O request based on the size of the data to be read from storage devices <NUM>, and may associate a priority tag to the I/O request in queue <NUM>, so that I/O process/storage pool <NUM> may determine the relative priority of the I/O request. For example, if the I/O request requests no more than <NUM> embedding vectors (rows of an embedding tables) of data to be read, the priority tag may indicate that the request has priority <NUM>; if the I/O request requests more than <NUM> embedding vectors of data but no more than <NUM> embedding vectors of data to be read, the priority tag may indicate that the request has priority <NUM>; and if the I/O request requests more than <NUM> embedding vectors of data to be read, then the priority tag may indicate that the request has priority <NUM>. As with the number of queues <NUM>, any number of different priorities may be used: three priorities as discussed above is merely an example number of priorities.

In some embodiments of the disclosure, queues <NUM> may be first in, first out (FIFO) queues. In other embodiments of the disclosure, other types of queues <NUM> may be used.

Note that even if there is only one queue <NUM>, the selection of the queue may still technically be based on the size of the I/O request (even if all I/O requests might be placed in that queue). Also, if there is only one queue, the queue might not be a FIFO queue. That is, I/O requests might be removed from the queue in a different order than they were added to the queue (for example, a priority <NUM> I/O request that is added to the queue later than a priority <NUM> I/O request might still be removed from the queue first and processed first).

Once I/O scheduler <NUM> has placed an I/O request in queues <NUM>, I/O process/storage pool <NUM> may retrieve the I/O request from queues <NUM>. By using multiple queues <NUM> (or by using different priorities), I/O process/storage pool <NUM> may select which I/O request to process next. In this manner, I/O requests may be processed by I/O process/storage pool <NUM> in a different order than they were sent to multi-process system <NUM> from applications running on processor <NUM> of <FIG>.

I/O process/storage pool <NUM> may retrieve I/O requests from queues <NUM> using any desired technique. For example, I/O process/storage pool <NUM> might use a round robin access, retrieving an I/O request from queue <NUM>-<NUM>, then an I/O request from queue <NUM>-<NUM>, then an I/O request from queue <NUM>-<NUM>, then back to queue <NUM>-<NUM>, and so on. (Of course, if a queue <NUM> has no I/O requests in it, then I/O process/storage pool <NUM> may skip that queue <NUM> and move to the next queue <NUM> to retrieve an I/O request.

I/O process/storage pool <NUM> may include manager <NUM>, which may be responsible for retrieving I/O requests from queues <NUM>. Manager <NUM> may also be responsible for determining which storage device(s) <NUM> store the requested data (the data might be stored on a single storage device <NUM>, or the data might be stored on multiple storage devices <NUM>). Once manager <NUM> has determined which storage device(s) <NUM> store the requested data, manager <NUM> may dispatch the I/O request to load module(s) <NUM>-<NUM> through <NUM>-<NUM> (which may be referred to collectively as load module(s) <NUM>) to read the data from the storage device(s) <NUM>.

In some embodiments of the disclosure, each storage device <NUM> may be considered as separate from the other storage devices <NUM>. That is, there might be no predetermined relationship between or among storage devices <NUM> governing their use. For example, each storage device <NUM> might be considered not only a physically separate storage device but also a logically separate storage device (which arrangement may be compared, for example, to a Redundant Array of Independent Disks (RAID), where management of the storage of data is left to the RAID controller). But in other embodiments of the disclosure, storage devices <NUM> may be configured as an array, such as a RAID.

To determine which storage device(s) <NUM> store the data requested in the I/O request, manager <NUM> may access table <NUM>. Table <NUM> may function similarly to a flash translation layer in a SSD. But instead of mapping a logical address (such as the logical block address of the data as used by the application) to a physical address (on the storage device), table <NUM> may map the logical address (or some other identifier of the data) to an identifier of storage device(s) <NUM> that store the requested data. Table <NUM> may be stored in some form of storage (for example, volatile storage such as local DRAM or non-volatile storage such as a firmware module or flash storage). The use of table <NUM> is discussed further with reference to <FIG> below.

Once manager <NUM> has dispatched the I/O request to load module(s) <NUM>, load module(s) <NUM> may access the requested data from storage device(s) <NUM>. For example, if the data is stored on storage device <NUM>-<NUM>, manager <NUM> may dispatch the I/O request to load modules <NUM>-<NUM> and/or <NUM>-<NUM>; if the data is stored on storage device <NUM>-<NUM>, manager <NUM> may dispatch the I/O request to load modules <NUM>-<NUM> and/or <NUM>-<NUM>. In <FIG>, I/O process/storage pool <NUM> is shown as including two storage devices <NUM> and four load modules <NUM>, embodiments of the disclosure may include any number (one or more) storage devices <NUM> and any number (one or more) load modules <NUM> (although there should be at least one load module <NUM> for each storage device <NUM>).

Note that in <FIG> each storage device <NUM> has two load modules <NUM> that may access data from the storage device. In some embodiments of the disclosure, storage devices <NUM> may support multi-threaded access: that is, storage devices <NUM> may support reading data to satisfy multiple requests concurrently. For example, if storage device <NUM> includes multiple channels, each of which may be used independently of the others, then one thread might request data stored along one channel, and another thread might request data stored on a second channel, with both threads operating concurrently. In embodiments of the disclosure that include multiple load modules <NUM> that may access a storage device <NUM> concurrently but the data might be accessible by only one load module <NUM>, table <NUM> may also include an identifier of the particular load module <NUM> to be used to retrieve the requested data. And in some embodiments of the disclosure, there might be only one load module <NUM> per storage device <NUM>. Embodiments of the disclosure may also include combinations of these possibilities: for example, one storage device <NUM> might support multiple threads and may be accessed by multiple load modules <NUM>, while another storage device <NUM> might not support multiple threads and so may be accessed by only one load module <NUM>.

In <FIG>, load modules <NUM> may be sparse length sum (SLS) load modules <NUM>. SLS load modules <NUM> are discussed further with reference to <FIG> below.

Load modules <NUM> may use, for example, a user-space non-volatile memory express (UNVMe) driver to access storage devices <NUM>. Whereas drivers by applications to access storage devices <NUM> may use a file system, UNVMe drivers may access data directly from storage devices <NUM>, and may not use a file system. Load modules <NUM> may also use various application programming interfaces (APIs) provided by storage devices <NUM> to access the data.

As discussed with reference to <FIG> above, storage devices <NUM> may be any desired varieties of storage devices, such as hard disk drives and SSDs. In addition, variations of these varieties may also be used. For example, storage devices <NUM> may be SSDs optimized to store and retrieve data to satisfy DLRM queries: such SSDs might have a different architecture from an SSD intended for general use.

In some embodiments of the disclosure, data requested in an I/O request might be stored on a specific storage device <NUM>. As a result, it might happen that multiple I/O requests may be sent to the same storage device <NUM>. When accessing data from a particular storage device <NUM>, load modules <NUM> may use submission queues to manage multiple requests of the same storage device <NUM>. Load modules <NUM> may also factor in the size of the request and the availability of submission queues in an attempt to balance the storage devices <NUM>.

In the above discussion, how the data is stored on storage devices <NUM> is not discussed. In some embodiments of the disclosure, storage devices <NUM> may be pre-loaded with the data, and table <NUM> may be prepared in advance; in other embodiments of the disclosure, the applications may request that the data be written to storage devices <NUM>, and manager <NUM> may select which storage device(s) <NUM> to write the data to (with table <NUM> being updated accordingly).

It would be desirable for data to be accessed roughly equally from across all storage devices <NUM> in I/O process/storage pool <NUM> (this feature may be described as load balancing). But depending on how the data is stored in storage devices <NUM> and what applications are requesting data from storage devices <NUM>, the loads on each storage device <NUM> might not be balanced. For example, while storage devices <NUM>-<NUM> and <NUM>-<NUM> might store equal amounts of data in terms of size, it might happen that, say, <NUM>% of the I/O requests request data stored on storage device <NUM>-<NUM> (and only <NUM>% of the I/O requests request data stored on storage device <NUM>-<NUM>). In such a situation, the unbalanced loads might result in higher than desirable latencies to access data from storage device <NUM>-<NUM>.

To adjust for such situations, I/O process/storage pool <NUM> may include a migration module (not shown in <FIG>). The migration module may be responsible for moving data around between or among storage devices <NUM> to achieve the desired balances. For example, some data might be migrated from storage device <NUM>-<NUM> to storage device <NUM>-<NUM> in an attempt to balance how much data is requested from each storage device.

There are other reasons why data might be moved between or among storage devices <NUM>. While read load balance may be an important objective, it may also be important to keep the capacities of the storage devices roughly in balance (for example, to support writing new data by another application that may be distributed across storage devices <NUM>). Or, some data may be accessed often enough, or be considered important enough, to justify such data being stored on multiple storage devices <NUM>, to provide for redundancy.

Regardless of why data is migrated (such as for storage capacity balancing, read load balancing, or redundancy), the migration tool may update table <NUM> to reflect such changes. That is, if data is migrated from storage device <NUM>-<NUM> to storage device <NUM>-<NUM>, table <NUM> may be updated to reflect the migration of that data.

<FIG> shows details of an input/output (I/O) request issued to multi-process system <NUM> of <FIG>, according to embodiments of the disclosure. In <FIG>, I/O request <NUM> is shown. I/O request <NUM> is shown as including identifier <NUM> and vectors <NUM>-<NUM> through <NUM>-<NUM> (which may be referred to collectively as vectors <NUM>). For example, vectors <NUM> might include <NUM> data points, but embodiments of the disclosure may include any number of data points per vector. Identifier <NUM> may be an identifier of the data requested from multipurpose system <NUM> of <FIG>. For example, identifier <NUM> may be a logical address of the data as used by the application running on processor <NUM> of <FIG>; but embodiments of the disclosure may use any desired identifier for the data.

Vectors <NUM> may identify specific vectors from the data that are of interest. As discussed above, DLRM queries may use data (embedding vectors) from embedding tables, which may be large (up to hundreds of GB or TB in size). But the queries might only depend on particular data within the table, and reading the entire table may take a long time relative to the amount of data actually needed. Instead, I/O request <NUM> may include vectors <NUM>, which may identify particular vectors of interest in the embedding table, and all other vectors may be ignored. While <FIG> shows vectors <NUM> in I/O request <NUM>, embodiments of the disclosure may include any number of vectors.

In addition, if I/O request <NUM> includes vectors <NUM>, then I/O scheduler <NUM> of <FIG> may be able to determine the size of the data to be read. For example, I/O scheduler <NUM> of <FIG> may determine the number of bytes to be read by multiplying the number of vectors <NUM> in I/O request <NUM> by the number of data points in each vector <NUM> and by the size of each data point in each vector <NUM>. If each vector <NUM> includes, for example, <NUM> data points, each of which requires four bytes, then the size of the data to be read by I/O request <NUM> may be determined as <NUM> (the number of vectors <NUM> in I/O request <NUM>) x <NUM> (the number of data points in each vector <NUM>) x <NUM> (the number of bytes for each data point) = <NUM>,<NUM> B.

While <FIG> shows I/O request <NUM> as including only identifier <NUM> and vectors <NUM>, embodiments of the disclosure may include other data, or may remove some of the data shown. For example, instead of including vectors <NUM>, I/O request <NUM> might include an offset from a logical address (in <FIG>, the logical address is used as identifier <NUM>, but embodiments of the disclosure might distinguish between identifier <NUM> and the logical address for the data, in which case the logical address might be a separate data included in I/O request <NUM>) and a number of bytes to be read (in which case the number of bytes to be read may be used to determine the size of I/O request <NUM>). Or, I/O request <NUM> might include various tags not shown in <FIG>. Embodiments of the disclosure may include any such variations on I/O request <NUM>.

<FIG> shows details of table <NUM> of <FIG>, according to embodiments of the disclosure. In <FIG>, table <NUM> is shown as including three entries. One entry maps identifier <NUM>-<NUM> of a first data to identifier <NUM>-<NUM> of a storage device storing that data; another entry maps identifier <NUM>-<NUM> of a second data to identifier <NUM>-<NUM> of a storage device storing that data; and a third entry maps identifier <NUM>-<NUM> of a third data to identifier <NUM>-<NUM> of a storage device storing that data. While <FIG> shows table <NUM> as including three entries, embodiments of the disclosure may include any number (zero or more) entries.

Note that identifiers <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> (which may be referred to collectively as identifiers <NUM>) are shown as identifying particular storage devices by numbers. Table <NUM> might not store the actual physical address, as that information may be stored by the storage device itself. Identifiers <NUM> may be replaced with other information that may uniquely identify storage devices: for example, using an identifier assigned to storage devices <NUM> of <FIG> during discovery and/or enumeration, or by using a serial number of storage devices <NUM> of <FIG>, among other possibilities.

While <FIG> suggests that each identifier <NUM> may be associated with a single unique identifier <NUM>, embodiments of the disclosure may map identifiers <NUM> to one or more identifiers <NUM>. If the data associated with identifier <NUM>-<NUM> is stored on multiple storage devices (for example, to provide redundancy), table <NUM> may reflect this fact. If the data in question is stored on multiple storage devices <NUM> of <FIG>, then manager <NUM> of <FIG> may have the option of assigning I/O request <NUM> of <FIG> to more than one load module <NUM> of <FIG>. This option may be useful, for example, in balancing the loads on storage devices <NUM> of <FIG> in I/O process/storage pool <NUM> of <FIG>. For example, if storage device <NUM>-<NUM> of <FIG> has a relatively large number of I/O requests <NUM> of <FIG> waiting to be processed and the data is available from both storage devices <NUM>-<NUM> and <NUM>-<NUM> of <FIG>, manager <NUM> of <FIG> might select load modules <NUM>-<NUM> or <NUM>-<NUM> of <FIG> to perform I/O request <NUM> from storage device <NUM>-<NUM> of <FIG>.

In some embodiments of the disclosure, data requested in I/O request <NUM> of <FIG> might be stored on a single storage device <NUM> of <FIG>. In such embodiments of the disclosure, identifier <NUM> may uniquely identify where the data represented by identifier <NUM> may be located. But in other embodiments of the disclosure, the data might be distributed across multiple storage devices <NUM> of <FIG>. In such embodiments of the disclosure, manager <NUM> of <FIG> might determine that all the data requested in I/O request <NUM> of <FIG> may be distributed across multiple storage devices <NUM> of <FIG>, and may split I/O request <NUM> of <FIG> into multiple different I/O requests, each to be sent to different load modules <NUM> of <FIG>. As table <NUM> may identify which storage device <NUM> of <FIG> stores what data, table <NUM> might include multiple entries for different portions of the data.

As an example, consider again I/O request <NUM> of <FIG>. I/O request <NUM> of <FIG> requests data from five vectors <NUM> of <FIG>. Manager <NUM> of <FIG> might determine that vectors <NUM>-<NUM> and <NUM>-<NUM> of <FIG> are stored on storage device <NUM>-<NUM> of <FIG>, and vectors <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> of <FIG> are stored on storage device <NUM>-<NUM> of <FIG>. In that case, manager <NUM> of <FIG> might send one I/O request to load modules <NUM>-<NUM> or <NUM>-<NUM> of <FIG> to read vectors <NUM>-<NUM> and <NUM>-<NUM> of <FIG>, and another I/O request to load modules <NUM>-<NUM> or <NUM>-<NUM> of <FIG> to read vectors <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> of <FIG>.

In addition, recall that multiple load modules <NUM> of <FIG> might have access to the same storage device <NUM> of <FIG>. In that case, even if the data to be read is stored on, for example, just storage device <NUM>-<NUM> of <FIG>, manager <NUM> of <FIG> might send two I/O requests: one to load module <NUM>-<NUM> of <FIG> and the other to load module <NUM>-<NUM> of <FIG>. In this manner, manager <NUM> of <FIG> might expedite the reading of the data from storage device <NUM>-<NUM> of <FIG>, even though a single load module <NUM> of <FIG> might be able to handle reading all the data from storage device <NUM>-<NUM> of <FIG>.

<FIG> shows details of I/O scheduler <NUM> of <FIG>, according to embodiments of the disclosure. In <FIG>, I/O scheduler <NUM> may include size calculator <NUM>, threshold <NUM>, comparator <NUM>, and queue selector <NUM>. As discussed above with reference to <FIG>, I/O scheduler <NUM> may use the size of I/O request <NUM> of <FIG> to select queue <NUM> of <FIG> into which I/O request <NUM> of <FIG> may be placed. Size calculator <NUM> of <FIG> may determine the size of I/O request <NUM> of <FIG>. Size calculator <NUM> may use, among other data, the number of bytes to be read from the data according to I/O request <NUM> of <FIG>, or the number of vectors <NUM> of <FIG> in combination with the number of data points in each vector <NUM> of <FIG> and the number of bytes per data point, to calculate the size of I/O request <NUM> of <FIG>.

Once the size of I/O request <NUM> of <FIG> has been determined by size calculator <NUM>, comparator <NUM> may compare the size of I/O request <NUM> of <FIG> with threshold <NUM>. Threshold <NUM> may be any desired threshold against which the size of I/O request <NUM> of <FIG> may be compared, and queue selector <NUM> may use this information in selecting among queues <NUM> of <FIG> to place I/O request <NUM> of <FIG>. If the size of I/O request <NUM> of <FIG>, as determined by size calculator <NUM>, is less than threshold <NUM> according to comparator <NUM>, then queue selector <NUM> may select one queue <NUM> of <FIG> to place I/O request <NUM> of <FIG>; otherwise, queue selector <NUM> may select another queue <NUM> of <FIG> to place I/O request <NUM> of <FIG>.

While <FIG> shows one threshold <NUM>, embodiments of the disclosure may include any number of thresholds <NUM>, and comparator <NUM> may compare the size of I/O request <NUM> of <FIG> against each threshold <NUM> until the largest threshold <NUM> which is smaller than the size of I/O request <NUM> of <FIG> is identified (or alternatively, until the smallest threshold <NUM> which is larger than the size of I/O request <NUM> of <FIG> is identified). Queue selector <NUM> may then use this information to select queue <NUM> of <FIG> to place I/O request <NUM> of <FIG>.

For example, as discussed above with reference to <FIG>, queue <NUM>-<NUM> of <FIG> might be used to store I/O requests to retrieve data no larger than, say, <NUM> embedding vectors; queue <NUM>-<NUM> of <FIG> might be used to store I/O requests larger than, say, <NUM> embedding vectors but no larger than, say, <NUM> embedding vectors; and queue <NUM>-<NUM> of <FIG> might be used to store I/O requests larger than, say, <NUM> embedding vectors. For this example, two thresholds <NUM> might be used: one at <NUM> embedding vectors and another at <NUM> embedding vectors. Thus, in some embodiments of the disclosure, the number of queues <NUM> of <FIG> may be one greater than the number of thresholds <NUM> (with thresholds <NUM> acting as the dividing lines between pairs of queues <NUM> of <FIG>).

<FIG> shows details of load module <NUM> of <FIG>, according to embodiments of the disclosure. As discussed with reference to <FIG> above, I/O request <NUM> of <FIG> might identify specific vectors <NUM> of <FIG> to be read from an embedding table. Because the number of vectors <NUM> of <FIG> in I/O request <NUM> of <FIG> may be small relative to the number of vectors in the data, most of the data may be ignored. Therefore, the data in storage devices <NUM> of <FIG> may be thought of as "sparse", in that most of the values may be ignored for purposes of satisfying I/O request <NUM> of <FIG>.

When load module <NUM> is a sparse length sum load module, load module <NUM> may read the specific vectors <NUM> of <FIG> identified in I/O request <NUM> of <FIG>, and add them together to produce a single vector. This sum of the identified vectors <NUM> of <FIG> may then be returned as the data requested by I/O request <NUM> of <FIG>.

To operate as SLS load module <NUM>, load module <NUM> may include reader <NUM> and adder <NUM>. Reader <NUM> may read the specific vectors <NUM> of <FIG> identified in I/O request <NUM> of <FIG> from storage device <NUM> of <FIG>. Note that in some embodiments of the disclosure reader <NUM> may access the data somehow from storage device <NUM> of <FIG>; in other embodiments of the disclosure reader <NUM> may issue the appropriate commands to storage device <NUM> of <FIG>, which may return the data to load module <NUM>. Adder <NUM> may then add the vectors retrieved from storage device <NUM> of <FIG> to produce the data to be returned in response to I/O request <NUM> of <FIG>.

<FIG> shows details of computation system <NUM> of <FIG>, according to embodiments of the disclosure. In <FIG>, computation system <NUM> may receive computation request <NUM>, which may be a request to process data retrieved by multi-process system <NUM> of <FIG> in response to I/O request <NUM> of <FIG>. Computation system <NUM> may include computation scheduler <NUM>, queues <NUM>-<NUM> and <NUM>-<NUM> (which may be referred to collectively as queues <NUM>), and processing elements <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> (which may be referred to collectively as processing elements <NUM>).

Computation scheduler <NUM> may place computation request <NUM> in one of queues <NUM> based on the workload of computation request <NUM>. For example, computation request <NUM> might involve resources that are offered by only one of processing elements <NUM>, which may determine in which queue <NUM> computation request <NUM> should be placed. Computation scheduler <NUM> may also consider how busy processing elements <NUM> are in assigning computation request <NUM> to processing elements <NUM>, as discussed below.

In some embodiments of the disclosure, queues <NUM> may be FIFO queues. In other embodiments of the disclosure, other types of queues <NUM> may be used.

Processing element <NUM> may then remove computation request <NUM> from queues <NUM> and process the request. Processing element <NUM> may be any desired type of processing element: for example, a central processing unit (CPU), a graphics processing unit (GPU), a general purpose GPU (GPGPU), a neural processing unit (NPU), a tensor processing unit (TPU), or an accelerator such as a Field Programmable Gate Array (FPGA) or Application-Specific Integrated Circuit (ASIC), among other possibilities. In addition, for elements that include multiple cores (for example, a multi-core CPU), each core may be considered a separate processing element <NUM>.

In some embodiments of the disclosure, each processing element <NUM> may have its own queue <NUM>, from which it may receive computation requests to process. That is, processing element <NUM> might process only computation requests assigned specifically to that processing element, and might ignore computation requests assigned to other processing elements. In other embodiments of the disclosure, two or more processing elements may share a queue. For example, as shown in <FIG>, processing elements <NUM>-<NUM> and <NUM>-<NUM> may both receive computation requests via queue <NUM>-<NUM>, whereas processing element <NUM>-<NUM> may receive computation requests via queue <NUM>-<NUM>. When a processing element has finished processing a computation request, the processing element may then examine the appropriate queue to see if another computation request is waiting that the processing element may process. If the processing element finds a computation request that it may process waiting, then the processing element may begin to process that computation request; otherwise, the processing element may go idle.

In some embodiments of the disclosure, a processing element might look for computation requests in multiple queues <NUM>. For example, processing element <NUM>-<NUM> might be able to process any computation request that processing elements <NUM>-<NUM> and <NUM>-<NUM> may process, but might be able to process some additional computation requests as well. In that situation, processing element <NUM>-<NUM> might retrieve computation requests from queue <NUM>-<NUM> as long as queue <NUM>-<NUM> has computation requests waiting to be processed ; if queue <NUM>-<NUM> is empty, the processing element <NUM>-<NUM> might retrieve a computation request from queue <NUM>-<NUM>.

Computation system <NUM> may also include ready queue <NUM>. Processing elements <NUM> may use ready queue <NUM> to inform computation scheduler <NUM> when they have finished processing a computation request. In this manner, computation scheduler <NUM> may keep track of how busy processing elements <NUM> are. For example, consider the situation where computation scheduler <NUM> receives computation request <NUM>, and assume that each processing element <NUM> has its own queue <NUM>. Computation scheduler <NUM> may determine that either of processing elements <NUM>-<NUM> or <NUM>-<NUM> may be capable of processing computation request. With no information about how busy processing elements <NUM>-<NUM> or <NUM>-<NUM> are, computation scheduler <NUM> might assign computation request <NUM> to the queues associated with processing elements <NUM>-<NUM> or <NUM>-<NUM> randomly. But if computation scheduler <NUM> receives information via ready queue <NUM> that processing element <NUM>-<NUM> has completed its most recent computation request (and therefore is currently idle), computation scheduler <NUM> may assign computation request <NUM> to processing element <NUM>-<NUM> without having to guess which of processing elements <NUM>-<NUM> or <NUM>-<NUM> have the lighted workload.

In a similar manner, while processing elements <NUM>-<NUM> or <NUM>-<NUM> might be the more desirable processing element to process computation request <NUM>, if both processing elements <NUM>-<NUM> and <NUM>-<NUM> are currently busy and processing element <NUM>-<NUM> is currently idle, computation scheduler <NUM> may schedule processing element <NUM>-<NUM> to process computation request <NUM>, even if processing element <NUM>-<NUM> is less desirable to process computation request <NUM>.

Computation request <NUM> may include a tag, identifying the computation request. Alternatively, computation scheduler <NUM> may assign a tag to computation request <NUM>, thereby identifying the computation request. Processing elements <NUM> may use these tags in ready queue <NUM> to inform computation scheduler <NUM> about what computation requests have been completed. In this manner, computation scheduler <NUM> may maintain an approximate idea of the workloads pending for processing elements <NUM> (by comparing what computation requests each processing element <NUM> has processed with what computation requests have been scheduled for each processing element <NUM>).

<FIG> shows a flowchart of an example procedure for processing the I/O request of <FIG> using multi-process system <NUM> of <FIG>, according to embodiments of the disclosure. In <FIG>, at block <NUM>, I/O scheduler <NUM> of <FIG> may receive I/O request <NUM> of <FIG>. At block <NUM>, I/O request <NUM> of <FIG> may be delivered from I/O scheduler <NUM> of <FIG> to load module <NUM> of <FIG>. Finally, at block <NUM>, load module <NUM> of <FIG> may read data from storage device <NUM> of <FIG> based on I/O request <NUM> of <FIG>.

<FIG> shows an alternative flowchart of an example procedure for processing I/O request <NUM> of <FIG> using multi-process system <NUM> of <FIG>, according to embodiments of the disclosure. In <FIG>, blocks that are similar to blocks in <FIG> may be assigned use the same figure reference numbers. In <FIG>, at block <NUM>, I/O scheduler <NUM> of <FIG> may receive I/O request <NUM> of <FIG>. At block <NUM>, size calculator <NUM> of <FIG> may determine the size of I/O request <NUM> of <FIG>. At block <NUM>, queue selector <NUM> of <FIG> may select queue <NUM> of <FIG> for I/O request <NUM> of <FIG>. At block <NUM>, I/O selector <NUM> of <FIG> may place I/O request <NUM> of <FIG> in queue <NUM> of <FIG> selected by queue selector <NUM> of <FIG>. Finally, at block <NUM>, load module <NUM> of <FIG> may read data from storage device <NUM> of <FIG> based on I/O request <NUM> of <FIG>.

<FIG> shows a flowchart of an example procedure for I/O scheduler <NUM> of <FIG> to use priority queueing in queueing I/O request <NUM> of <FIG>, according to embodiments of the disclosure. In <FIG>, at block <NUM>, I/O scheduler <NUM> of <FIG> may determine a priority tag for I/O request <NUM> of <FIG>, based on the size of I/O request <NUM> of <FIG> (which may be determined by size calculator <NUM> of <FIG>). At block <NUM>, I/O scheduler <NUM> of <FIG> may associate the priority tag with I/O request <NUM> of <FIG> in queue <NUM> of <FIG>.

<FIG> shows a flowchart of an example procedure for manager <NUM> of <FIG> to assign I/O request <NUM> of <FIG> to load module <NUM> of <FIG>, according to embodiments of the disclosure. In <FIG>, at block <NUM>, manager <NUM> of <FIG> may retrieve I/O request <NUM> of <FIG> from queue <NUM> of <FIG>. At block <NUM>, manager <NUM> of <FIG> may identify storage device <NUM> of <FIG> storing the data. This may involve, for example, mapping identifier <NUM> of <FIG> of the data to identifier <NUM> of <FIG> of the storage device storing the data using table <NUM> of <FIG>, as shown at block <NUM>. At block <NUM>, manager <NUM> of <FIG> may identify load module <NUM> of <FIG> that has access to storage device <NUM> of <FIG>. Finally, at block <NUM>, manager <NUM> of <FIG> may send I/O request <NUM> of <FIG> to load module <NUM> of <FIG>.

<FIG> shows a flowchart of an example procedure for load module <NUM> of <FIG> to read data from the storage device of <FIG>, according to embodiments of the disclosure. In <FIG>, at block <NUM>, reader <NUM> of <FIG> may read vectors <NUM> of <FIG> from storage device <NUM> of <FIG>. At block <NUM>, adder <NUM> of <FIG> may sum vectors <NUM> of <FIG>. Finally, at block <NUM>, multi-process system <NUM> of <FIG> may send the data to computation scheduler <NUM> of <FIG> of computation system <NUM> of <FIG>, for use in processing computation request <NUM> of <FIG>.

<FIG> shows a flowchart of an example procedure for computation system <NUM> of <FIG> to process the computation request of <FIG>, according to embodiments of the disclosure. In <FIG>, at block <NUM>, computation scheduler <NUM> of <FIG> may schedule processing of computation request <NUM> of <FIG> using the data read by multi-process system <NUM> of <FIG> in response to I/O request <NUM> of <FIG>. At block <NUM>, processing element <NUM> of <FIG> may receive computation request <NUM> of <FIG> from computation scheduler <NUM> of <FIG>. For example, in block <NUM> computation scheduler <NUM> of <FIG> may place computation request <NUM> of <FIG> in queue <NUM> of <FIG>, and in block <NUM> processing element <NUM> of <FIG> may retrieve computation request <NUM> of <FIG> from queue <NUM> of <FIG>.

At block <NUM>, processing element <NUM> of <FIG> may process computation request <NUM> of <FIG>. Finally, at block <NUM>, processing element <NUM> of <FIG> may inform computation scheduler <NUM> of <FIG> that it has completed processing of computation request <NUM> of <FIG>. For example, processing element <NUM> of <FIG> may place information in ready queue <NUM> of <FIG> to inform computation scheduler <NUM> of <FIG> that processing element <NUM> of <FIG> has completed processing of computation request <NUM> of <FIG>. In some embodiments of the disclosure, block <NUM> may be omitted (for example, if only one computation request <NUM> of <FIG> is scheduled at processing element <NUM> of <FIG> and computation scheduler <NUM> of <FIG> knows how long it should take processing element <NUM> of <FIG> to process computation request <NUM> of <FIG>), as shown by dashed line <NUM>.

<FIG> show a flowchart of an example procedure for computation scheduler <NUM> of <FIG> to arrange for processing element <NUM> of <FIG> to process computation request <NUM> of <FIG>, according to embodiments of the disclosure. In <FIG>, at block <NUM>, computation scheduler <NUM> of <FIG> may select processing element <NUM> of <FIG> to process computation request <NUM> of <FIG>. At block <NUM>, computation scheduler <NUM> of <FIG> may send computation request <NUM> of <FIG> to processing element <NUM> of <FIG>. Alternatively, at block <NUM>, computation scheduler <NUM> of <FIG> may assign computation request <NUM> of <FIG> to queue <NUM> of <FIG>.

Alternative to block <NUM>, at block <NUM> (<FIG>), computation scheduler <NUM> of <FIG> may identify a type of processing element <NUM> of <FIG> suited to process computation request <NUM> of <FIG>. At block <NUM> computation scheduler <NUM> of <FIG> may assign computation request <NUM> of <FIG> to queue <NUM> of <FIG> appropriate to the type of processing element <NUM> of <FIG>.

In yet another alternative to block <NUM>, at block <NUM> computation scheduler <NUM> of <FIG> may determine a workload of computation request <NUM> of <FIG>. At block <NUM>, computation scheduler <NUM> of <FIG> may assign computation request <NUM> of <FIG> to queue <NUM> of <FIG> based on the workload of computation request <NUM> of <FIG>.

In <FIG>, some embodiments of the disclosure are shown. But a person skilled in the art will recognize that other embodiments of the disclosure are also possible, by changing the order of the blocks, by omitting blocks, or by including links not shown in the drawings. All such variations of the flowcharts are considered to be embodiments of the disclosure, whether expressly described or not.

Embodiments of the disclosure include a multi-process system. The multi-process system may load data from an input/output (I/O) process/storage pool using an I/O request, which may be based on the data to be processed using a computation request. Data may be retrieved using load modules associated with the storage devices in the I/O process/storage pool. The use of multiple storage devices provides a technical advantage over data being stored in a single storage device by leveraging parallel data access from the multiple storage devices to achieve a low latency in reading the data.

Different I/O requests may be queued in different queues. The use of multiple queues provides a technical advantage in that I/O requests that may involve large or small amounts of data are not delayed by multiple I/O requests of other data sizes.

Data retrieved by the multi-process system may be provided to a computation system. The computation system may schedule computation requests using the data. The computation system may use different queues based on the workloads of the computation requests, providing a technical advantage to satisfy the query per second promised by a service level agreement.

Deep learning recommendation model (DLRM) workloads may be input/output (I/O) intensive. In order to meet their service level agreement (SLA) requirements, dynamic random access memory (DRAM) may be needed to store big embedding tables (up to <NUM> GB or more). Such large amounts of DRAM may be expensive.

For a small query size, a Solid State Drive (SSD) with a user space driver may be used to store embedding tables to satisfy an SLA. But for a reasonably large query size (>=<NUM>), it might be difficult for a single SSD to meet the SLA. Furthermore, with a single SSD, it may not be possible to execute queries in parallel to achieve a high query per second (QPS), because of a potential input/output (I/O) bottleneck in the SSD.

A query scheduler based on computations with multiple SSDs may have a low efficiency and may experience load balancing issues (with some SSDs handling a larger percentage of queries and other SSDs handling a smaller percentage of queries). SSDs handling large numbers of queries might have insufficient I/O to handle the queries (much like the single SSD model), and SSDs handling small numbers of queries may be underutilized.

Embodiments of the disclosure may include a multiple process and multiple SSD system with I/O scheduler to achieve high QPS and low latency. A schedule embedding table IO may be used to schedule queries to different I/O queues.

The I/O process/SSD pool may fetch I/O requests from I/O queues based on the load status and I/O request for the various SSDs.

Inside the I/O process/SSD pool, multiple SSDs may be accessed by multiple-process user-space non-volatile memory express (UNVME) driver/application programming interface (API) with various number of active threads to satisfy I/O requests.

A second level computation scheduler may be used to further optimize computation latency and QPS based on computation intensity.

The following discussion is intended to provide a brief, general description of a suitable machine or machines in which certain aspects of the disclosure may be implemented. The machine or machines may be controlled, at least in part, by input from conventional input devices, such as keyboards, mice, etc., as well as by directives received from another machine, interaction with a virtual reality (VR) environment, biometric feedback, or other input signal. As used herein, the term "machine" is intended to broadly encompass a single machine, a virtual machine, or a system of communicatively coupled machines, virtual machines, or devices operating together. Exemplary machines include computing devices such as personal computers, workstations, servers, portable computers, handheld devices, telephones, tablets, etc., as well as transportation devices, such as private or public transportation, e.g., automobiles, trains, cabs, etc..

The machine or machines may include embedded controllers, such as programmable or non-programmable logic devices or arrays, Application Specific Integrated Circuits (ASICs), embedded computers, smart cards, and the like. The machine or machines may utilize one or more connections to one or more remote machines, such as through a network interface, modem, or other communicative coupling. Machines may be interconnected by way of a physical and/or logical network, such as an intranet, the Internet, local area networks, wide area networks, etc. One skilled in the art will appreciate that network communication may utilize various wired and/or wireless short range or long range carriers and protocols, including radio frequency (RF), satellite, microwave, Institute of Electrical and Electronics Engineers (IEEE) <NUM>, Bluetooth®, optical, infrared, cable, laser, etc..

Embodiments of the present disclosure may be described by reference to or in conjunction with associated data including functions, procedures, data structures, application programs, etc. which when accessed by a machine results in the machine performing tasks or defining abstract data types or low-level hardware contexts. Associated data may be stored in, for example, the volatile and/or non-volatile memory, e.g., RAM, ROM, etc., or in other storage devices and their associated storage media, including hard-drives, floppy-disks, optical storage, tapes, flash memory, memory sticks, digital video disks, biological storage, etc. Associated data may be delivered over transmission environments, including the physical and/or logical network, in the form of packets, serial data, parallel data, propagated signals, etc., and may be used in a compressed or encrypted format. Associated data may be used in a distributed environment, and stored locally and/or remotely for machine access.

Embodiments of the disclosure may include a tangible, non-transitory machinereadable medium comprising instructions executable by one or more processors, the instructions comprising instructions to perform the elements of the disclosures as described herein.

The various operations of methods described above may be performed by any suitable means capable of performing the operations, such as various hardware and/or software component(s), circuits, and/or module(s). The software may comprise an ordered listing of executable instructions for implementing logical functions, and may be embodied in any "processor-readable medium" for use by or in connection with an instruction execution system, apparatus, or device, such as a single or multiple-core processor or processorcontaining system.

The blocks or steps of a method or algorithm and functions described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a tangible, non-transitory computer-readable medium. A software module may reside in Random Access Memory (RAM), flash memory, Read Only Memory (ROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), registers, hard disk, a removable disk, a CD ROM, or any other form of storage medium known in the art.

Claim 1:
A system (<NUM>), comprising:
a storage device (<NUM>-<NUM>) configured to store data;
a sparse length sum, SLS, load module (<NUM>-<NUM>) configured to read the data from the storage device (<NUM>-<NUM>) based at least in part on an input/output, I/O, request (<NUM>), wherein the I/O request (<NUM>) includes a first identifier (<NUM>) of the data and vectors (<NUM>);
a scheduler (<NUM>) configured to receive the I/O request (<NUM>) and to place the I/O request (<NUM>) in a queue (<NUM>-<NUM>) for delivery to the SLS load module (<NUM>-<NUM>) based at least in part on the size of the I/O request (<NUM>) being less than a threshold (<NUM>);
a second storage device (<NUM>-<NUM>) configured to store second data; and
a second SLS load module (<NUM>-<NUM>) configured to read the second data from the second storage device (<NUM>-<NUM>); and
a manager (<NUM>) configured to retrieve the I/O request (<NUM>) from the queue (<NUM>-<NUM>) and to assign the I/O request (<NUM>) to the SLS load module (<NUM>-<NUM>) based on a table (<NUM>) mapping the first identifier (<NUM>) of the data to a second identifier (<NUM>) of the storage device that store the requested data, wherein the table (<NUM>) identifies particular storage devices by numbers.