DE112014006118T5 - Speculative prefetching of data stored in a flash memory - Google Patents

Abstract

A method for data storage includes adhering to a definition of a speculative read-out mode for reading in a data storage device in which the data storage device requests to read a data unit having a data unit size, and in response the data storage device retrieves a data storage page containing the data unit and has a larger data storage page size than the data unit size, and keeps the data storage page in preparation for subsequent requests. Activation of the speculative readout mode is coordinated. A read command is executed using the speculative readout mode.

Description

FIELD OF THE INVENTION

The present invention relates generally to data storage, and more particularly to methods and systems for prefetching data stored in nonvolatile memory.

BACKGROUND OF THE INVENTION

Some computing systems use virtual memory (VM) techniques that use fast, but small, volatile memory and large, but slower, non-volatile memory. For example, in some mobile computing and communication devices, the operating system (OS) includes a VM module that mounts the random access memory (RAM) of the device with a solid state drive (SSD). ) operates together.

Various methods of using VM are known in the art. For example, that describes U.S. Patent 8,429,377 , the disclosure of which is incorporated herein by reference, a system and method for accessing a memory. The system includes a processor device that issues a request for a memory page at a virtual address, and a lookup buffer for storing one or more page table entries, wherein each of the page table entries includes at least one virtual page number and a physical page number. The system further includes a logic circuit that receives a virtual address from the processor and compares the virtual address to the virtual page number in a particular one of the page table entries to select the physical page number in the same page table entry. The page table entry includes one or more bits that are set to exclude a memory area from a page.

IFIP WG 8.8 / 11.2 International Conference, CARDIS 2010, Passau, Germany, April 2010, pages: "Key-Study to Execute Code Using Demand Paging and NAND Flash at Smart Card Scale", Smart Card Research and Advanced Application 102 to 117, which is incorporated herein by reference, Geoffroy et al. Limitations that embedding multiple applications into such small systems as smart cards or sensors. Physical limitations of these systems, such as a very small main memory, and their production costs make this difficult to achieve. One particular solution proposed in the study is to execute code from a cheaper, denser but slower secondary storage, such as a NAND flash.

SUMMARY OF THE INVENTION

An embodiment of the present invention provides a method that includes adhering to a definition of a speculative read-out mode for reading in a data storage device by requesting the data storage device to read a data unit having a data unit size and, in response, the data storage device retrieving a data storage page containing the data unit and having a larger data storage page size than the data unit size, and storing the data storage page in preparation for subsequent requests. Activation of the speculative readout mode is coordinated. A read command is executed using the speculative readout mode.

In some embodiments, coordinating the activation includes receiving an instruction to read a single data unit in the data storage device, and executing the read command includes reading the individual data unit from the stored data storage page. In other embodiments, executing the read-out command upon detecting that the single data unit is not in the retained data storage page includes reporting an error event. In still other embodiments, executing the read command further includes discarding the retained data storage page after all data units in the stored data storage page have been requested.

In one embodiment, executing the read command includes receiving a request to read a given data unit in the stored data storage page, and outputting the given data unit and all subsequent data units from the retained data storage page in the data storage device. In yet another embodiment, coordinating the activation includes reporting the data storage page size from the data storage device. In yet another embodiment, the method further includes receiving a write command to store data sized equal to the data storage page size and storing the data to a page boundary of the data storage device aligned in the data storage device.

In addition, according to a data storage device including a non-volatile memory and a processor is provided. Of the The processor is configured to capture a definition of a speculative read mode in which the data storage device requests to read a data unit having a data unit size, and in response the data storage unit retrieves from the nonvolatile memory a data storage page containing the data unit and having a larger data storage page size than has the data unit size, and keeps the data storage page in preparation for subsequent requests to coordinate activation of the speculative readout mode, and to execute a read-out command using the speculative readout mode.

The present invention will become more fully understood from the following detailed description of the embodiments thereof, taken in conjunction with the drawings, in which:

BRIEF DESCRIPTION OF THE DRAWINGS

1 Fig. 12 is a block diagram schematically illustrating a data storage system according to an embodiment of the present invention;

2 to 4 Show diagrams schematically illustrating data caching and reading as part of speculative prefetching;

5 Figure 5 is a flowchart schematically illustrating a method for speculative prefetching of data by storing the data aligned on page boundaries according to an embodiment of the present invention; and

6 FIG. 10 is a flowchart schematically illustrating a method for reducing the startup duration of applications in accordance with an embodiment of the present invention. FIG.

DETAILED DESCRIPTION OF EMBODIMENTS

overview

Embodiments of the present invention described herein provide improved methods and systems for virtual memory (VM) operation. In many data storage systems, the space that an operating system (OS) allocates for a given process in the volatile memory of the host (hereafter referred to as "local memory") is not sufficient to contain all the code and data of the process. For example, this scenario may occur if the total local memory space is less than the space that the process requires, or if the OS is running multiple processes at the same time.

In some embodiments, the OS includes a virtual memory subsystem (VM) that manages the memory for processes executing in local memory. In the embodiments described herein, the VM manages the local memory and a large nonvolatile memory, such as a Flash Driven Solid State Drive (SSD). The VM allows a process to use a storage space that is larger than the space allocated for that process by the OS. Occasionally, the process may attempt to access data that is currently unavailable locally. Such an event is called a page fault event. The VM typically responds to page faults by fetching the data in question from the SSD.

The VM accesses data in the SSD in units, referred to herein as data chunks or data units. Upon detecting (or receiving an indication of) a page fault, the VM retrieves the corresponding missing data from the SSD by requesting the block of data to which the missing data belongs (also referred to as the missing block). In order to improve the access rate to missing data, in some embodiments the VM may be configured to fetch one or more subsequent data blocks in addition to the missing block. This mode of operation is referred to as speculative prefetching. However, speculative prefetching in SSD-based data storage systems can be problematic, as further described below.

Typically, the OS further includes a File System (FS) subsystem that manages the storage of data (eg, user or other data) in logical structures such as files and directories. The FS stores files in the SSD. A computer program can execute or otherwise use one or more files. For example, an application program may access a large number of small files, such as executable and multimedia files. When an application is run, the FS first uploads the appropriate application files from the SSD to local storage, and the host then runs the application from local storage. The process of uploading the files of an application is called application startup. Since the application files should be uploaded before running, a shorter application startup time will result in a better user experience.

In the host, the OS VM and FS subsystems typically manage the memory in a continuous logical address space. The SSD typically includes an SSD controller (SSD controller) that manages the memory in physical addresses of the flash memory. Logical addresses correspond to physical addresses of data blocks in the flash memories. The SSD controller typically maintains a translation table between logical and physical addresses.

The SSD controller stores data in the SSD in units that are referred to simply as pages for data storage pages or for brevity. In some cases, the VM (or FS) is configured to fetch data blocks smaller than the page size of the SSD. In other words, a page in the SSD typically includes multiple data blocks, of which the VM can request one each. As described below, this size variance between data storage pages and data blocks can negate potential benefits of speculative prefetching.

In some embodiments, the OS reads data in units, referred to herein as blocks or segments. The block size may be 512 bytes or 4 kilobytes (KB), for example. On the other hand, data in the SSD is written to and retrieved from flash memory in data storage pages whose size is typically larger than the block size. Example page sizes include 8 KB, 16 KB, and 32 KB.

In one embodiment, in response to a page fault event, the VM requests the corresponding missing block (i.e., the block that includes the missing data that generated the page fault) from the SSD. In principle, the VM can perform speculative prefetching by requesting one or more subsequent blocks in addition to the missing block. However, this pre-fetch operation would not improve the rate of accessing missing data because the SSD will fetch an entire page for each block request, even if the VM requests multiple blocks within the same page. In addition, such redundant page fetch operations cause increased power consumption, which shortens the battery or battery life of the system.

In the disclosed techniques, if the VM requests a missing block, the page containing that block is retrieved and cached in the SSD. If the VM then requests one or more blocks that are already cached (e.g., when performing speculative prefetching), those blocks are flushed from the cached page without creating an unnecessary re-read of the corresponding page from the SSD ,

In the description that follows, we assume an underlying SSD data store that includes an SSD controller and a volatile cache. For the sake of clarity, the nonvolatile memory of the SSD is referred to as "flash memory" unless otherwise specified. The flash memory may include any suitable number of individual flash devices.

In one embodiment, the host VM issues a request to the SSD to fetch a missing block and additionally issues a speculative prefetch operation to the SSD controller. The SSD controller retrieves the page to which the requested block belongs from the flash memory and caches the page. The SSD controller provides the requested block to the host and retains the cached page until the VM requests all other blocks of the cached page.

In one embodiment, the VM reads blocks that are part of a page that is already cached in the SSD by instructing the SSD controller to read each such block from the cached page without rescanning the entire page from the flash memory. Memory to read. However, if the VM requests a cached block, but the requested block is not in the cached page, the SSD controller issues the VM with a corresponding error indication. The VM can then read this block with or without caching the corresponding page. Reading a cached block is faster than reading the block from the flash memory.

In some embodiments, the VM performs speculative prefetching by requesting a missing block and additionally notifying the SSD via the speculative prefetching operation. The SSD retrieves the page to which the requested block belongs from flash memory, caches the page, and outputs the requested block and all subsequent blocks in the cached page to the host.

In principle, speculative prefetching may be more efficient if a single VM request causes the SSD controller to fetch blocks with page boundary alignment. However, the VM has no explicit knowledge of the location of individual blocks in the page, and therefore the VM can not explicitly request blocks that are aligned to page boundaries.

In one embodiment, the SSD controller reports to the VM the page size used in the flash memory. The VM then stores data in units with the received page size, while additionally instructing the SSD controller to store each such page aligned alignment device in the flash memory. When the VM later reads the corresponding stored data, the VM performs speculative prefetching as described above by fetching the first block in a page, and in response to the request for speculative prefetching, the SSD reads the page, to which the first block belongs, and store it between and deliver the entire page to the host.

When launching an application, it may be advantageous to do a speculative prefetch to reduce startup duration, for example, if the application files are sequentially stored in flash memory. However, when uploading any of the application files, the FS is unaware that the files are common to an application program and has no explicit indication to switch to a speculative prefetch mode when uploading these files. In one embodiment, the OS indicates the FS when an application start is initiated. In response, the FS then switches to reading the appropriate application files in speculative prefetching mode.

In some embodiments, the OS indicates the SSD controller when an application startup is started and terminated. In response, the SSD monitors the logical and corresponding physical addresses of the uploaded files of the launched application. The SSD controller then reorders the application files sequentially in a contiguous range of physical addresses in the flash memory to allow for subsequent efficient launching of the same application using speculative prefetching.

In alternative embodiments, the OS indicates the FS (instead of the SSD) whenever the OS initiates and terminates an application launch. The FS stores the logical addresses of the uploaded application files and sends the held addresses to the SSD controller using a dedicated defragmentation command. The SSD controller then reorders the application files sequentially in the flash memory and updates the address translation table accordingly.

The disclosed techniques make it possible to perform speculative prefetching to improve the rate of accessing missing data in detecting page fault events and to reduce the duration of launching applications while ignoring unnecessary read operations from the flash memory. The disclosed techniques thus improve read latency, power consumption and battery or battery life of the system.

system Description

1 FIG. 12 is a block diagram schematically illustrating a memory system according to an embodiment of the present invention. FIG. In the present example, the storage system includes a computer 20 , the data in a semiconductor drive (SSD) 24 stores. The computer 20 For example, it may include a mobile computer, tablet computer, or personal computer. The computer includes a central processing unit (CPU) 26 that serves as a host. In the description that follows, the terms CPU and host are used interchangeably.

In alternative embodiments, the host may comprise any other suitable processor or any other suitable control unit, and the data storage device may comprise any other suitable device. For example, the host may include a data storage controller of a corporate data storage system, and the data storage device may include an SSD or an array of SSDs. Other examples of hosts that store data in nonvolatile data storage devices include mobile phones, digital cameras, media players, and changeover cards or devices.

In one embodiment, the CPU performs 26 an operating system (OS) 27 from that the different tasks of the computer 20 unwinds. The OS also includes a file system (FS) 28 and a Virtual Memory Subsystem (VM) 29 , The FS 28 handles the organization of user data (and other data) in logical structures, such as directories and files. The VM 29 manages the memory for processes that put the FS into a volatile host memory 32 uploads and executes the OS from it. The memory 32 is also referred to as a local store. The memory 32 may include any suitable type of volatile memory, such as DDR, DDR2, DDR3, DDR3L, SDRAM or RDRAM. In a typical application, the memory has 32 a size between 1 GB and 32 GB, although any other suitable size can be used.

The SSD 24 stores data for the CPU 26 in a nonvolatile memory, in this example in one or more flash memory storage devices 34 , In alternative embodiments, the nonvolatile memory may be in the SSD 24 any other suitable type of nonvolatile memory, such as NOR Flash, Charge Trap Flash (CTF), Phase Change RAM (PRAM), Magnetoresistive RAM (MRAM), or Ferroelectric RAM ( Ferroelectric RAM (FeRAM)).

An SSD control unit 30 performs the various data storage and management tasks of the SSD. The SSD controller is also commonly referred to as a memory controller. The SSD control unit 30 includes a host interface 38 to communicate with the CPU 26 , a storage interface 46 to communicate with the flash devices 34 and a processor 42 performing the various processing tasks of the SSD.

The SSD 24 includes a volatile memory, in the present example a random access memory (RAM) 50 , In the embodiment of 1 is the RAM 50 as part of the SSD control unit 30 although the RAM may alternatively be disconnected from the SSD controller. The RAM 50 For example, static RAM (Static RAM (SRAM)), Dynamic RAM (DRAM), a combination of the two types of RAM, or any other suitable type of volatile memory may be included. The RAM 50 can be used for caching from the flash devices 34 read data are used before the data or parts thereof to the CPU 26 or to the host memory 32 to be delivered. As described below, the RAM stores 50 in some embodiments, a data page between, upon request, one or more data blocks to the CPU 26 to be delivered.

The lower part of 1 FIG. 4 illustrates an exemplary detailed block diagram of the NAND flash device. FIG 34 In the present example, the device comprises 34 a read / write (R / W) unit 70 which converts data into data storage values for storage in the memory device and converts them into memory cells (eg, analog memory cells) of a flash memory device 76 writes. In alternative embodiments, the R / W unit does not perform the conversion, but is provided with voltage samples, ie, the data storage values for storage in the cells. The R / W unit typically (though not necessarily) programs the memory cells using an iterative Program and Verify (P & V) process, as known in the art. When reading data from the arrangement 76 converts the R / W unit 70 the data storage values of the memory cells into digital samples with a resolution of one or one or more bits. Data is typically written to and read from the memory cells in groups called data pages or simply pages. Flash devices, such as the devices 34 , typically include 8K, 16K, or 32K pages. In some embodiments, the R / W unit may include a group of cells in the memory array 76 , z. For example, a block containing multiple pages may be erased by exposing the cells to one or more negative erase pulses.

The memory arrangement 76 For example, a "single-level cell" (SLC) memory device that stores 1 bit / cell using two levels of programming, or a "multi-level cell" (MLC) memory array may include the N bits / cell at ^2N programming levels stores. For example, a 2-bit / cell device uses four levels of programming, and a 3-bit / cell device uses eight levels of programming.

Some memory devices include two or more separate memory cell arrays, often referred to as planes. For example, in a two-level device in which each layer has pages of 16 KB, the SSD controller can retrieve 32 KB in a single read operation using multi-level access.

The processor 42 the SSD control unit 30 typically maintains a logical-to-physical address translation, which includes the physical data storage locations (also referred to as physical addresses) corresponding to the addresses specified by the host in the flash devices 34 maps and stores the data to the appropriate physical data storage locations. The logical-to-physical address translation (also referred to as virtual-to-physical mapping (V2P) may be in RAM 50 , in the flash devices 34 or stored in both.

The logical and corresponding physical addresses access data units, referred to herein as data blocks. In some embodiments, the size of a data page is greater than the size of a data block. For example, the VM can be configured with 4KB data blocks and the flash memory can be configured with 16KB pages. Typically, although not necessary, a data page comprises an integer number of data blocks.

The SSD control unit 30 and especially the processor 42 can be implemented in hardware. Alternatively, the SSD control unit may have a microprocessor containing appropriate software or a combination of hardware and software elements.

In the configuration of 1 it is an exemplary configuration shown for the sake of conceptual clarity only. Any other suitable SSD or memory system configuration may also be used. Elements that are not necessary for understanding the principles of the present invention, such as various interfaces, addressing circuits, timing and sequencing circuits, and debugging circuits, have been omitted from the figure for clarity. In some applications, eg. Non-SSD applications, for example, are the functions of the SSD controller 30 executed by a suitable memory control unit.

In the in 1 The exemplary system configurations shown are the memory devices 34 and the SSD control unit 30 implemented as separate integrated circuits (ICs). However, in alternative embodiments, the memory devices and the SSD controller may be integrated on separate semiconductor chips in a single multi-chip package (MCP) or a single system on a chip (SoC) and interconnected by an internal bus be connected. Still alternatively, some or all of the SSD controller circuitry may reside on the same component on which one or more of the memory devices 34 are arranged. Further alternatively, some or all of the functionality of the SSD controller may be 30 be implemented in software and by the CPU 26 or another processor running in computer. In some embodiments, the CPU 26 and the SSD control unit 30 on the same component or on separate components in the same device package.

In some embodiments, the processor includes 42 and / or the CPU 26 a universal processor programmed in software to perform the functions described herein. The software may be downloaded to the processor in electronic form, for example, over a network, or alternatively or additionally, may be provided and / or stored on non-transmittable, subject-matter media, such as magnetic, optical or electronic storage.

VM prefetching in SSD-based data storage systems

In the description that follows, let's assume that the VM 29 Data from the flash memories 34 in blocks or segments of a fixed size. In some embodiments, the SSD controller informs 30 the OS 27 about the minimum unit size for a data transfer via the host interface 38 ie the block size, such as 512 bytes or 4 KB. In the description that follows, assume a block size of 4 KB. Alternatively, however, any other suitable block size may be used.

If a software process or an application running through the OS 27 from the host memory 32 is running, must access data stored locally in memory 32 are not available, a page fault event occurs. If a page fault occurs, the VM issues one or more I / O requests to the SSD controller to retrieve the missing data from the corresponding flash drives 34 pick up. The data block to which the missing data belongs is also referred to as the missing block. Although the VM can fetch only a single block (ie, the missing block) at a time, in many cases the VM, as it progresses, is likely to have to fetch additional, subsequent data blocks. It is therefore typically more efficient to fetch a continuous area of multiple blocks rather than just the missing block. In the context of the present invention and in the claims, the term "speculative prefetching" refers to fetching one or more additional blocks following the missing block. In speculative prefetching, the fetched blocks may include one or more blocks preceding the missing block.

As demonstrated below, configuring the VM 29 To work in speculative prefetch mode, redundant read operations from the flash memories 34 generate, which leads to increased latency and increased energy consumption. For example, it is assumed that each of the flash memory 34 Sides of 16 KB stores. If the VM 29 requesting a single 4 KB data block, the SSD controller should read the entire 16 KB page to which this block belongs and the host 26 only deliver the requested block. If subsequent VM requests access other pages, the other three blocks read (12 KB in this example) will not be used. In addition, if the VM 29 Specifically pre-fetching multiple blocks of 4 KB all in the same page, each individual VM request generates a separate read of the entire page of 16 KB, and for each such read only 4 KB of the 16 KB page are sent to the host 26 delivered. As can be seen, the above examples demonstrate a bandwidth utilization of only 25% (4 KB of 16 KB).

The disclosed techniques, described below, allow the VM to perform speculative prefetching without wasting bandwidth and power consumption. By defining new VM operations, in the disclosed techniques, the SSD controller may once read and cache a data page and provide the cached data blocks of that page upon request to the host.

Method for efficient speculative prefetching

2 to 4 Figure 12 shows diagrams schematically illustrating data caching and reading as part of speculative prefetching. That in each of 2 to 4 Diagram shown comprises three columns. The leftmost and rightmost columns refer to operations performed by the VM 29 or through the SSD control unit 30 be performed. In each diagram, the middle column represents a cached page of 16 KB, comprising four 4 KB data blocks. Each diagram also includes a plurality of rows representing a single VM operation and a corresponding SSD controller operation per row. Each graph thus represents a sequence of VM operations that are performed over time. In the diagrams of 2 to 4 For example, each 4KB block is indicated by its respective physical address, such as ADR1, ADR2, and so forth. Thus, for example, the block ADR3 refers to the data block whose physical address in the flash memories is ADR3. In the disclosed methods, the SSD controller stores pages between the flash memories 34 in the RAM 50 be retrieved.

We now refer to 2 , In this example, we assume a page of 16KB that contains four 4K sequential blocks whose physical addresses are labeled ADR1 through ADR4. In the first operation, namely READ_VM1 (ADR3), the VM requests the block ADR3, but additionally gives the SSD control unit 30 a speculative prefetching operation. The SSD control unit 30 responds by reading the page of 16 KB in which the requested block is stored in the flash memories and stores the page in RAM 50 between. The cached page comprises the blocks ADR1 to ADR4. Then deliver the SSD control unit 30 only block ADR3 from the cached page to the host 26 ,

Next, the VM executes an operation READ_NO_SENSE (ADR1) in which the VM requests block ADR1, which indicates to read the block from the cached page. The SSD control unit 30 responds by reading the cached block ADR1 and to the host 26 without reading the entire page of 16 KB again. Next comes the VM 29 Similarly, an operation READ_NO_SENSE (ADR2) off to the SSD control unit 30 to cause the cached block ADR2 to be read and delivered to the host.

When performing the operation READ_NO_SENSE (ADR5), the VM requests the block ADR5, which is not part of the cached blocks ADR1 to ADR4. As a result, the SSD controller responds 30 by giving the VM an event READ_NO_SENSE_MISS. The error event indicates to the VM that the requested block is not yet cached and can not be read using the READ_NO_SENSE operation.

When the VM requests block ADR4 using the operation READ_NO_SENSE (ADR4), the SSD controller reads 30 cached block ADR4 and delivers it to the host. In addition, since the VM completes requesting all cached blocks ADR1 through ADR4 (not necessarily in a sequential order) by this operation, the SSD control unit releases the cached page to use the same memory location in the RAM 50 to allow caching of other pages.

3 describes another method of speculative prefetching. Although the VM requests a single block of 4 KB, in one embodiment, the VM prepares, from the SSD controller 30 up to the entire page of 16 KB, to which the requested block belongs. In the example of 3 gives the VM 29 a VM operation, ie READ_VM_TO_END (ADR7) to fetch block ADR7. The SSD control unit 30 responds by reading and caching the page comprising the four consecutive blocks ADR6 through ADR9, and provides to the host only the requested and all subsequent blocks (an operation to read to the end of the page), ie, ADR7 through ADR9 , Additionally provides the SSD control unit 30 together with the data blocks, the number of blocks delivered and their respective logical addresses to the VM. Following the delivery of the data blocks gives the SSD control unit 30 free the cached page for caching from other pages. The function of reading to the end of the page saves redundant requests by the VM that would otherwise be output separately for individual data blocks (typically including per-block memory acquisition and read operations), and therefore makes direct memory access (DMA) operations. ) of the OS more efficiently.

4 describes yet another method for efficient speculative prefetching. The method allows fetching data blocks previously stored with alignment to the physical addresses of page boundaries. In the example of 4 gives the SSD control unit 30 the VM 29 first the page size, in this example 16 KB. The VM accepts the specified page size for use in subsequent VM operations. Then the VM gives 29 the SSD control unit 30 issue a WRITE_VM_ALINGED command to write 16 KB of page boundary data. The SSD control unit 30 takes the WRITE_VM_ALINGED command and stores the 16 KB of data in four consecutive blocks so that the physical address of the first block matches the physical address of a complete page. In the example of 4 The four blocks to be written (the 16 KB of data) are stored in a page whose address is ADR6. Since the VM knows the logical addresses of any data written on page boundaries, the VM can later speculate that data as complete pages.

At a later time, the VM performs an operation READ_VM_TO_END (ADR6) to request the page storing blocks ADR6 = ADR9. The SSD control unit 30 responds to this command by caching the entire corresponding page, delivering the four blocks ADR6 through ADR9 to the host, and releasing the cached page.

In some embodiments, the SSD controller employs a block compression process, also referred to as garbage collection (GC). In this process, the SSD controller copies valid data from partially valid source blocks into one or more destination blocks. Since GC typically copies entire blocks or pages, data written aligned on page boundaries, as described above, maintains alignment even after being copied by the GC process.

5 FIG. 10 is a flowchart that schematically illustrates a speculative prefetching method according to an embodiment of the present invention by initially storing the data aligned on page boundaries. The procedure is controlled by the SSD control unit 30 executed and starts in an indication step 100 by the SSD control unit 30 the VM 29 the page size of the flash memory 34 indicates. In the example of 5 the page size is 16 KB. As described herein, the VM uses 29 the specified page size to write blocks of data aligned to page boundaries, allowing for efficient speculative prefetching of this data.

In a command receiving step 104 takes the SSD control unit 30 from the VM 16 KB to data to be stored using the WRITE_VM_ALIGNMENT command (described above). In an outlier save step 108 selects the SSD control unit 30 a corresponding page in the flash memory 34 and stores the four blocks of 4 KB that contain the 16 KB of data, aligned to the boundaries of the selected page. The VM 29 tracks the logical addresses of 16K data pages that are stored aligned to physical page boundaries. In a speculative read command receiving step 112 takes the SSD control unit 30 from the VM 29 a request against, the entire page in step 108 was stored speculatively.

In step 116 translates the SSD control unit 30 the logical address of the requested page into a corresponding physical address, reads the page data and stores the page in RAM 50 between. In step 116 For example, the VM may use the READ_VM_TO_END operation (described above) or a dedicated other VM operation that provides the entire cached page to the host. The SSD controller then provides in a page delivery step 120 the 16 KB of the cached page through the host interface 38 to the VM 29 , Further, in step 120 the SSD controller caches the cached page in RAM 50 Free to allow reuse of the same storage space for caching additional pages.

Fast application start

An application program often accesses a large number of relatively small files, which is the FS 28 in the flash memory 34 stores when the application is installed. The application files may include executable files, bitmap files, multimedia files, and the like. If the OS 26 an application starts loading the FS 28 in some embodiments, the files of the application of corresponding locations in the flash memories 34 in the host memory 32 to run high. The FS 28 uploads the application files by going to the SSD control unit 30 a plurality of corresponding read commands are sent. The amount of time needed to start the application files should be short so that the user suffers from a minimal delay before he can use the application.

Various methods for accelerating the startup time of applications are known in the art. Example methods are described by Yongsoo et al. in "FAST: quick application launch on solid state drives", Proceedings of the 9th USENIX on February 25-17, 2011, San Jose, USA, which is incorporated herein by reference.

In some embodiments described herein, the FS uses 28 speculative prefetching to reduce the duration of launching applications. For example, the FS 28 Use speculative prefetch methods as described in the above 2 to 4 described.

In one example embodiment, the application files are sequentially stored in a contiguous range of physical addresses in one of the flash memories. When receiving identifications of the application files from the OS 27 it would be for the FS 28 you have been able to read each of the application files separately from Flash memory with speculative prefetching turned off. However, this would lead to redundant read operations in the flash memory and therefore with a long startup time, especially if the size of the files is on the order of the block size (eg 4 KB) or less.

In a disclosed embodiment, the OS 27 in addition to providing the identification of the application files the FS 28 indicates that the files belong together to an application program. Upon receiving this note, the FS will change 28 automatically in the mode speculative prefetching, in which the FS 28 speculative prefetching, such as described above with respect to 2 to 4 described, used to efficiently read multiple blocks of 4 KB.

6 FIG. 12 is a flowchart that schematically illustrates a method for reducing the startup duration of applications in accordance with an embodiment of the present invention. The procedure is controlled by the SSD control unit 30 is executed and starts in a start-start hint step 200 by giving the SSD control unit an indication or a hint from the OS 27 that an application startup process has begun. While in a monitoring step 204 the FS 28 the application files reads, monitors the SSD control unit 30 The logical and corresponding physical addresses of the read data of the uploaded files and holds them.

In a start completion step 208 takes the SSD control unit 30 from the OS 27 an indication that the FS 28 completed the upload of the application files, and the SSD control unit 30 accordingly, the sticking stops in step 204 was executed. The SSD control unit then arranges in a defragmentation step 212 redesign the application files to occupy a contiguous range of physical addresses. On step 212 Following the procedure ends. Defragmenting the application files into a contiguous physical space makes subsequent launches of that application more efficient (eg, using speculative prefetching) and therefore improves the user experience due to shorter startup time.

In alternative embodiments, the OS 27 the FS 28 (instead of the SSD control unit 30 as in procedures of 6 ) to begin holding the logical addresses of the application files upon initiation of an application start and to stop the capture when the application start ends. In such embodiments, the FS 28 following the startup completion, a dedicated defragmentation command to the SSD controller 30 out. In defragmentation command takes the SSD control unit 30 from the FS 28 the logical addresses of the application files. The SSD controller then performs defragmentation by reordering the application files into a contiguous range of physical addresses.

The methods described above are exemplary methods, and other methods may be used in alternative embodiments. For example, although the data block and page sizes are 4 KB and 16 KB, respectively, in all the methods described above, any other sizes may be used.

Although typically the VM and the FS share the same data block size, as another example in alternative embodiments, the methods described above may be applied such that the VM and FS fetch data blocks of different sizes (both sizes are smaller than the page size). Alternatively or additionally, the VM (or FS) may use different block sizes for different processes or applications.

The disclosed methods are applicable not only to SSD-based data storage systems, but to any data storage systems in which, for each fetch of a missing data block by the VM (or FS), a page whose size is larger than the block size is from the underlying memory is retrieved.

Although the embodiments described herein primarily address a memory device communicating host processor in an SSD-based data storage system, the methods and systems described herein may also be used in other applications, such as in any system in which a host is configured to store data in Storing blocks that are smaller than the data storage unit used by the underlying data storage device.

It will therefore be understood that the above-described embodiments are presented by way of example, and that the present invention is not limited to what has been shown and described in detail hereinabove. Rather, the scope of the present invention includes both combinations and sub-combinations of the various features described hereinabove, as well as variations and modifications thereof which occur to those skilled in the art upon reading the foregoing description, and which are not disclosed in the prior art. Documents incorporated by reference into the present application are to be considered as an integral part of the application, except to the extent that any terms in these incorporated documents are defined in a manner consistent with those expressed or implied in the present application Patent definitions are conflicting, only the definitions in the present specification are to be considered.

Claims (17)

A method of data storage comprising: Maintaining a definition of a speculative read-out mode for reading in a data storage device, requesting the data storage device to read a data unit having a data unit size, and in response, the data storage device retrieving a data storage page containing the data unit and having a data storage page size larger than the data unit size , and the data store page kept in preparation for subsequent requests; Coordinating activation of the speculative readout mode; and Execute a read command using the speculative readout mode. The method of claim 1, wherein coordinating the activation comprises receiving a command to read a single data unit in the data storage device, and wherein executing the read command comprises reading the individual data unit from the retained data storage page. The method of claim 2, wherein executing the read-out command upon detecting that the single data unit is not in the retained data storage page comprises reporting an error event. The method of claim 2, wherein executing the read command further comprises discarding the retained data storage page after all data units in the retained data storage page have been requested. The method of claim 1, wherein executing the read command comprises receiving a request to read a given data unit in the stored data storage page and outputting the given data unit and all subsequent data units from the stored data storage page in the data storage device. The method of claim 1, wherein coordinating the activation comprises reporting the data storage page size from the data storage device. The method of claim 1, and receiving a write command to store data sized equal to the data storage page size and storing the data on a page boundary of the data storage device aligned in the data storage device. A data storage device comprising: a non-volatile memory; and a processor configured to capture a definition of a speculative read mode in which the data storage device requests to read a data unit having a data unit size, and in response, the data storage unit retrieves from the nonvolatile memory a data storage page containing the data unit; has larger data storage page size than the data unit size and keeps the data storage page in preparation for subsequent requests to coordinate activation of the speculative readout mode and to execute a readout command using the speculative readout mode. The data storage device of claim 8, wherein the processor is configured to receive a command to read, receive, and execute the read-out command by reading the single data unit from the retained data storage page. The data storage device of claim 9, wherein the processor is configured, upon detecting that the single data unit is not in the retained data storage page, to report an error event. The data storage device of claim 9, wherein the processor is further configured to discard the retained data storage page after all data units in the retained data storage page have been requested. The data storage device of claim 8, wherein the processor is configured to receive a request to read a given data unit in the stored data storage page, and to output the given data unit and all subsequent data units from the stored data storage page. The data storage device of claim 8, wherein the processor is configured to report the data storage page size. The data storage device of claim 8, wherein the processor is configured to receive a write command to store data sized equal to the data storage page size and to store the data aligned with a page boundary of the data storage device. Device comprising: a host configured to execute an operating system; a data storage device; and a processor configured to receive an indication from the operating system indicating that a plurality of read commands to be issued to the data storage device are associated with a start of an application to be executed by the operating system and to jointly execute the plurality of read commands in response to the hint. The device of claim 15, wherein the processor is configured to execute the plurality of read commands using speculative prefetching. The device of claim 16, wherein the processor is configured to reorder data read by the plurality of read commands in a contiguous range of physical addresses in the data storage device.

Images