Method and apparatus for persistently caching storage data in a page cache

Abstract

The present invention relates to methods and apparatus for persistently caching data in a page cache. In one embodiment, an apparatus includes a memory to store executable instructions of an operating system; and a processor to: identify a request for data from an application; determine whether a persistent page cache stores a copy of the data, wherein the persistent page cache is directly addressable by the processor and is to cache data of a storage device that is not directly addressable by the processor; and access the data from the persistent page cache.

Description

TECHNICAL FIELD

[0001] The present disclosure relates generally to the field of computer development, and more specifically to data caching. BACKGROUND

[0002] A computer system can include one or more central processing units (CPUs) that can communicate with one or more storage devices. The CPUs can include processors to execute an operating system and / or other software applications that utilize the storage devices coupled to the CPUs. The software applications can write data to the storage devices and read data from the storage devices. BRIEF DESCRIPTION OF DRAWINGS

[0003] Figure 1 FIG. illustrates a block diagram of components of a computer system implementing an operating system-based cache, in accordance with certain embodiments.

[0004] Figure 2 FIG. illustrates a block diagram of components of a computer system implementing an operating system-based cache, in accordance with certain embodiments.

[0005] Figure 3 FIG. illustrates a block diagram of components of a computer system implementing a persistent page cache, in accordance with certain embodiments.

[0006] Figure 4 FIG. illustrates a block diagram of components of a computer system implementing a persistent memory file system and a persistent page cache, in accordance with certain embodiments.

[0007] Figure 5 FIG. illustrates a block diagram of components of a computer system implementing a persistent memory file system shim layer and a persistent page cache, in accordance with certain embodiments.

[0008] Figure 6 FIG. illustrates an example flow for providing data from a page cache to a processor, in accordance with certain embodiments.

[0009] Like reference numbers and designations in the various drawings indicate like elements. DETAILED DESCRIPTION

[0010] While the drawings depict specific computer systems, the concepts of the various embodiments are applicable to any appropriate computer system. Examples of systems in which the teachings of this disclosure can be used include desktop computer systems, server computer systems, storage systems, handheld devices, tablets, other thin notebooks, system on a chip (SoC) devices, and embedded applications. Some examples of handheld devices include cellular phones, digital cameras, media players, personal digital assistants (PDAs), and handheld PCs. Embedded applications can include microcontrollers, digital signal processors (DSPs), SOCs, network computers (NetPCs), set-top boxes, network hubs, wide area network (WAN) switches, or any other system that can perform the functions and operations taught below. Various embodiments of the present disclosure can be used in any appropriate computing environment, such as a personal computing device, a server, a mainframe, a cloud computing service provider infrastructure, a data center, a communication service provider infrastructure (e.g., one or more portions of an Evolved Packet Core), or other environments including one or more computing devices.

[0011] Figure 1 A block diagram illustrating components of a computer system 100, in accordance with some embodiments, is shown. The system 100 includes a central processing unit (CPU) 102 coupled to an external input / output (I / O) controller 104, a storage device 106, a volatile system memory device 108, and a persistent system memory device 110. During operation, data can be transferred between the storage device 106 and the CPU 102, between the volatile system memory device 108 and the CPU 102, between the persistent system memory device 110 and the CPU 102, or between any of the storage device 106, the volatile system memory device 108, and the persistent system memory device 110. In various embodiments, specific data operations (e.g., read or write operations) involving the storage device 106, the volatile system memory device 108, or the persistent system memory device 110 can be issued by an operating system 122 and / or by other logic (e.g., applications 124) executed by the processor 111.

[0012] An operating system-based cache is a cache technology in which a host computing device (e.g., a CPU) executes logic that controls the caching of data stored on a storage device (e.g., a hard drive) to a smaller and faster cache storage device (e.g., a solid state drive (SSD)). When an application executed by the host requests data that the host is not currently caching, the data can be retrieved from the storage device and stored in memory that the host computing device can more easily access (i.e., the data can be cached by the host). For example, data retrieved from a storage device (e.g., a hard disk drive (HDD)) can be cached by storing the retrieved data in a cache storage device (e.g., an SSD), a system memory device, and / or one or more lower level caches of a CPU. After the data is cached, the data can be retrieved from one of the caches rather than from the storage device, thereby reducing the amount of latency for accessing the data by the host.

[0013] In an operating system-based cache system, the operating system can coordinate the caching of stored data from a storage device in a storage cache device that includes persistent (i.e., non-volatile) memory as well as a page cache in volatile system memory (e.g., dynamic random access memory (DRAM)). A page cache (which is sometimes also referred to as a buffer cache or a disk cache) is a cache of pages of data corresponding to a storage device, such as an HDD. The operating system can maintain the page cache in otherwise unused portions of system memory (e.g., the operating system can use physical memory not directly allocated to an application for the page cache), resulting in faster access to the contents of the cached pages. The page cache is generally transparent to applications (i.e., applications are unaware of whether retrieved data is from the page cache or from the storage device).

[0014] In general, system memory can be directly addressable by the CPU (e.g., addressable by the processor directly), while storage devices are not. For example, a memory space can be directly addressable by the processor if the CPU can construct a physical address for the data based on an address provided in an instruction executed by the processor. As an example, the processor 111 of the CPU 102 can directly address system memory by using load and store primitives (e.g., load and store instructions executed by the cores 114A and 114B). In various embodiments, the address specified in the load and store primitives can be a physical address of the system memory or a virtual address that is interpreted into a physical address by the CPU 102 (e.g., via a memory management unit of the CPU). In contrast, an external storage device (e.g., the storage device 106 or a cache storage device) is not directly addressable by the CPU because the CPU 102 must interpret a memory address specified by an instruction (or a physical address corresponding to a virtual address specified by the processor) into a logical block address of the storage device 106 (which the storage device 106 then interprets into a physical address of the requested data on the storage device 106). As another example, a memory space can be directly addressable by the processor if the memory space can provide data to a location within the processor (e.g., in response to a load instruction by the processor). For example, a system memory can provide requested data to a register of the processor such that the data is immediately available, while a storage device must first copy the data to the system memory before the data is available for use by the processor (which can require the processor to retry the instruction after the data has been brought into the system memory).

[0015] While the page cache in the system memory of a storage system provides CPU addressability, caching in the storage cache device provides persistence (i.e., a power failure will not result in loss of stored data). However, utilizing a volatile page cache and a storage cache device results in various deficiencies. Due to the volatility of the page cache, the operating system typically must populate the page cache at each reboot of the computer system by copying data from the storage cache device to the volatile page cache. Additionally, the capacity of the volatile page cache is typically much smaller than the capacity of the cache storage device. This causes the stored data to be evicted from the volatile page cache to the cache storage device and then repopulated back into the volatile page cache based on application access patterns, resulting in additional overhead. Additionally, because the page cache is volatile, the data stored therein needs to be frequently flushed to the cache storage device for persistence. This frequent flushing results in a significant performance overhead, especially for concurrent writes. In parallel with other data stored in the volatile system memory, managing the page cache also incurs a relatively large cost, such as during scanning of page lists when inactive pages are evicted to swap space. Additionally, caching the stored data in the volatile page cache can consume precious volatile memory, thus reducing the amount of volatile memory available to the operating system and applications to store associated code and volatile data.

[0016] In various embodiments of this disclosure, computing system 100 includes a page cache 136 stored in persistent memory 134, such as three-dimensional (3D) intersection memory (or other persistent memory described herein). The persistent page cache 136 provides both CPU addressability and persistence for cached stored data (i.e., data with a corresponding copy stored in storage device 106). Accordingly, the cached data remains available in the address space of CPU 102 even after a computer system restart, without having to move the data from the address space of storage device 106 after a restart. This also reduces the need for frequent copying of stored data between volatile system memory devices and non-volatile storage cache devices. It significantly reduces the latency for hitting I / O requests in the persistent page cache (which might be missed in the volatile page cache). Persistent commit primitives (e.g., instructions requesting data to be moved from the page cache to persistent memory, such as calls to fsync and msync) result in minimal overhead because the associated data will already be stored in the persistent page cache (e.g., such instructions may only include updating metadata indicating that the data is stored in persistent memory). The use of volatile memory is reduced, freeing it up for application use (operating systems typically use a portion of volatile system memory for page caching, while the remainder can be used by applications). Additionally, scanning the page list to free up volatile memory for applications can be completed more quickly because scanning pages in the persistent page cache 136 is unnecessary. Ultimately, the persistent page cache 136 enables efficient data journaling for implementing transactions in the file system. By using the persistent page cache 136 as an implicit data journaling log, the need for separate data journaling is eliminated. Typical file systems stage transactions in a DRAM-based page cache and then flush those transactions to persistent storage (i.e., to the cache storage device) upon transaction commit. Because page cache 136 is persistent, transactions in persistent page cache 136 can be committed using a slightly modified logging protocol without flushing data to persistent storage, resulting in improved transaction performance in the file system (or other storage management software such as object storage systems).

[0017] CPU 102 includes processor 111, such as a microprocessor, embedded processor, DSP, network processor, handheld processor, application processor, coprocessor, SOC, or other device for executing code (i.e., software instructions). In the depicted embodiment, processor 111 includes two processing elements (cores 114A and 114B in the depicted embodiment), which may include asymmetric or symmetric processing elements. However, the processor may include any number of processing elements, which may be symmetric or asymmetric.

[0018] In one embodiment, a processing element refers to hardware or logic used to support software threads. Examples of hardware processing elements include: thread units, thread slots, threads, processing units, contexts, context units, logic processors, hardware threads, cores, and / or any other elements capable of maintaining state (such as execution state or architectural state) for the processor. In other words, in one embodiment, a processing element refers to any hardware that can be associated independently of code (such as software threads, operating systems, applications, or other code). A physical processor (or processor socket) generally refers to an integrated circuit, which can potentially include any number of other processing elements, such as cores or hardware threads.

[0019] Core 114 can refer to logic located on an integrated circuit capable of maintaining independent architectural states, where each independently maintained architectural state is associated with at least some dedicated execution resources. Hardware threads can refer to any logic located on an integrated circuit capable of maintaining independent architectural states, where independently maintained architectural states share access to execution resources. As can be seen, hardware thread naming overlaps with core naming when some resources are shared and others are dedicated to an architectural state. However, often, the operating system treats cores and hardware threads as separate logical processors, where the operating system can schedule operations independently on each logical processor.

[0020] In various embodiments, the processing element may also include one or more arithmetic logic units (ALUs), floating-point units (FPUs), caches, instruction pipelines, interrupt handling hardware, registers, or other hardware that facilitates the operation of the processing element.

[0021] I / O controller 112 is an integrated I / O controller that includes logic for communicating data between CPU 102 and I / O devices. It can refer to any suitable logic capable of passing data to and / or receiving data from electronic systems (such as CPU 102). For example, I / O devices may include: controllers for audio / video (A / V) devices such as graphics accelerometers; controllers for data storage devices (such as SSDs, HDDs, non-volatile dual in-line memory modules (NVDIMMs), or optical storage disks (e.g., storage device 106); wireless transceivers; network processors; network interface controllers; or controllers for other input devices (such as monitors, printers, mice, keyboards, or scanners); or other suitable devices. In one particular embodiment, the I / O device may include a storage device controller (not shown) for storage device 106.

[0022] I / O devices can communicate with the I / O controller 112 of CPU 102 using any appropriate signaling protocol, such as Peripheral Component Interconnect (PCI), Fast PCI (PCIe), Universal Serial Bus (USB), Serial Attached SCSI (SAS), Serial ATA (SATA), Fibre Channel (FC), IEEE 802.3, IEEE 802.11, or other current or future signaling protocols. In certain embodiments, the I / O controller 112 and the underlying I / O devices may communicate data and commands according to a Fast Non-Volatile Memory (NVMe) or a logical device interface specification of Advanced Host Controller Interface (AHCI) as described in one or more of the specifications available at www.nvmexpress.org / specifications / (e.g., as described in one or more AHCI specifications (such as Serial ATAAHCI: Specification, Revision 1.3.1) available at http: / / www.intel.com / content / www / us / en / io / serial-ata / serial-ata-ahci-spec-rev1-3-1.html). In various embodiments, the I / O devices coupled to the I / O controller may be located off-chip (i.e., not on the same chip as CPU 102) or may be integrated on the same chip as CPU 102.

[0023] Memory controller 116 is an integrated memory controller including logic for controlling the flow of data to and from one or more system memory devices (sometimes referred to as main memory), such as volatile system memory device 108 or persistent system memory device 110. Memory controller 116 may include logic operable to read from, write to, or request other operations from system memory devices. In various embodiments, memory controller 116 may receive write requests from core 114 and / or I / O controller 112 (e.g., when storage device 106 performs a direct memory access (DMA) operation) and may provide the data specified in these requests to the system memory devices for storage therein. Memory controller 116 may also read data from system memory devices and provide read data to I / O controller 112 or core 114. During operation, memory controller 116 may issue commands including one or more addresses of system memory devices to read data from memory or write data to memory (or to perform other operations). In some embodiments, the memory controller 116 may be implemented on the same chip as the CPU 102, while in other embodiments, the memory controller 116 may be implemented on a different chip than the CPU 102. The I / O controller 112 may perform similar operations with respect to one or more storage devices 106.

[0024] Volatile memory controller 118 can communicate commands and data with volatile system memory device 108, and persistent memory controller 120 can communicate commands and data with persistent system memory device 110. In the depicted embodiment, volatile system memory device 108 and persistent system memory device 110 are shown as separate devices, although in other embodiments, volatile memory 126 and persistent memory 134 may be integrated on the same device. Similarly, memory controller 116 is shown as including separate volatile and persistent memory controllers (118 and 120), although in other embodiments, a single memory controller may communicate with both volatile system memory device 108 and persistent system memory device 110 (or a single device including volatile memory 126 and persistent memory 134). Memory controller 116 may be operable to determine whether a request should be sent to volatile memory 126 or persistent memory 134 based on the address of the request, and may format the request accordingly.

[0025] CPU 102 can also be coupled to one or more other I / O devices (such as those listed above or any other suitable I / O devices) via external I / O controller 104. In one particular embodiment, external I / O controller 104 may couple storage device 106 to CPU 102. External I / O controller 104 may include logic for managing data flow between one or more CPUs 102 and I / O devices. In one particular embodiment, external I / O controller 104 is positioned on a motherboard together with CPU 102. External I / O controller 104 may exchange information with components of CPU 102 using point-to-point or other interfaces.

[0026] Volatile system memory device 108 can store any suitable data, such as data used by processor 111 to provide functionality for computer system 100. In the depicted embodiment, volatile memory 126 stores page cache 128, application code 130, and application data 132. In one particular embodiment, volatile memory 126 does not store page cache 128 (instead of implementing the entire page cache in persistent memory 134). However, as explained in more detail below, in some cases it may be advantageous to maintain page cache 128 in volatile memory 126 for a portion of the cached data and page cache 136 in persistent memory 134 for the cached data.

[0027] Page cache 128 or 136 may cache physical pages (sometimes referred to as frames) of stored data in storage device 106. Page cache 128 may be maintained by volatile memory 126 (which is also used by applications executed by processor 111) by operating system 122 (e.g., page cache 128 may be implemented using memory remaining after other portions of volatile memory 126 have been used for application code and data), while in at least some embodiments, page cache 136 may be dedicated to caching data. Application code 130 may include executable instructions associated with an application (e.g., a text segment). Application data 132 may include: a stack segment storing a set of frames, which stores function parameters, return addresses, local variables, or other data; a stack segment used when the application dynamically allocates memory at runtime; a data segment including static variables and initialized global variables; a segment storing uninitialized global and static variables; and / or any other suitable data associated with one or more applications 124 executed by operating system 122.

[0028] In one particular embodiment, page cache 128 or 136 may use a radix tree structure to cache file data. Each file whose data is stored in the page cache can be represented by a radix tree (which can be identified, for example, by an inode in a Linux-based operating system). The radix tree maps file offsets (represented using page nodes of the radix tree) to data pages in the page cache. When a page is cached in the page cache, file data is read from the storage device and stored in the leaf nodes of the radix tree. Obsolete data in the radix tree (data that has been modified by processor 111 and has not yet been written back to storage device 106) is written to storage device 106 synchronously (e.g., using a full synchronous (fsync) operation) or asynchronously (e.g., using periodic write-back).

[0029] In various embodiments, the operating system 122 may maintain a page table for each active application, which stores information used to determine the physical memory pages residing in the system memory device based on virtual addresses (e.g., instructions executed by core 114). In some embodiments, the page table may be stored in a volatile memory device or a persistent memory device, and individual virtual page addresses may be mapped to physical page addresses in the volatile memory device or the persistent memory device.

[0030] System memory devices (such as volatile system memory device 108 and / or persistent system memory device 110) may be dedicated to a specific CPU 102 or shared with other devices of the computer system 100 (such as one or more other processors or other devices). In various embodiments, the system memory device may be checked to see if it stores the requested data after making a decision that the last-level cache of CPU 102 does not include the requested data.

[0031] In various embodiments, the system memory device may include memory, which includes any number of memory modules, memory device controllers, and other supporting logic (not shown). Memory modules may include persistent memory and / or volatile memory. Volatile system memory device 108 includes volatile memory 126 and persistent system memory device 110 includes persistent memory 134, although in some embodiments either system memory device may include both volatile and persistent memory.

[0032] Volatile memory is a storage medium that requires power to maintain the state of the data stored on it. Examples of volatile memory can include various types of random access memory (RAM), such as dynamic random access memory (DRAM) or static random access memory (SRAM). One particular type of DRAM that can be used in a memory module is synchronous dynamic random access memory (SDRAM). In some embodiments, memory 108 as any part of volatile memory can comply with JEDEC standards, including but not limited to dual data rate (DDR) standards (e.g., DDR3, 4, and 5) or low-power DDR4 (LPDDR4) and emerging standards.

[0033] Persistent memory is a storage medium that does not require power to maintain the state of data stored by the medium. In various embodiments, persistent memory can be byte- or block-addressable. Non-limiting examples of persistent memory may include any one or a combination of the following: solid-state memory (such as planar or 3D NAND flash memory or NOR flash memory), 3D cross-point memory, memory using chalcogenide phase change materials (e.g., chalcogenide glass), ferroelectric memory, silicon oxide-nitrogen oxide-silicon (SONOS) memory, polymer memory (e.g., ferroelectric polymer memory), ferrite transistor random access memory (Fe-TRAM) bidirectional memory, nanowire memory, electrically erasable programmable read-only memory (EEPROM), memristors, single-level or multi-level phase change memory (PCM), spin Hall effect magnetic RAM (SHE-MRAM), and spin-transfer torque magnetic RAM (STTRAM).

[0034] Storage device 106 can store any suitable data, such as data used by processor 111 to provide functionality for computer system 100. For example, data associated with programs executed by cores 114A and 114B or files accessed by cores 114A and 114B can be stored in storage device 106. In various embodiments, storage device 106 can store persistent data (e.g., user files or software application code) that maintains its state even after power to storage device 106 is removed. Storage device 106 can be dedicated to CPU 102 or shared with other devices of computer system 100 (e.g., another CPU or other devices).

[0035] In various embodiments, system device 106 may include a solid-state drive; a hard disk drive; a memory card; an NVDIMM; a tape drive; or other suitable mass storage device. In a particular embodiment, storage device 106 is a block-based storage device that stores data blocks addressable by a host computing device (e.g., CPU 102) via local block addresses (LBAs).

[0036] Storage device 106 may include any suitable interface for communicating with I / O controller 112 or external I / O controller 104 using any appropriate communication protocol (such as DDR-based protocols, PCI, PCIe, USB, SAS, SATA, FC, System Management Bus (SMBus), or other appropriate protocols). Storage device 106 may also include a communication interface for communicating with I / O controller 112 or external I / O controller 104 according to any appropriate logical device interface specification (such as NVMe, AHCI, or other appropriate specifications).

[0037] In various embodiments, the storage device 106 also includes an address interpretation engine comprising a logical (e.g., one or more logical-to-physical (L2P) address tables) mapping between a logical address space (e.g., an address space visible to a computing host coupled to the storage device 106) and the physical address space of the storage medium of the storage device 106 (which may or may not be exposed to a computing host). The logical address space may expose multiple logical groups of data, which are physically stored on corresponding physical memory groups addressable by the storage device 106 through its physical address space. Therefore, the L2P address tables can be interpreted between LBAs provided by the host and the physical addresses of the corresponding data. In one particular embodiment, an LBA specifies the minimum amount of data (sometimes referred to as a page) that can be referenced using write or read commands. In various examples, an LBA may refer to a block size of 512 bytes, 1 kilobyte (KB), 2KB, 4KB, or other suitable block size.

[0038] In some embodiments, all or some of the components of system 100 reside on (or are coupled to) the same circuit board (e.g., motherboard). In various embodiments, any suitable partitioning may exist between the components. For example, the components depicted in CPU 102 may be located on a single die (i.e., on a chip) or package, or any of the components of CPU 102 may be located outside the chip or outside the package.

[0039] The components of system 100 can be coupled together in any suitable manner. For example, a bus can couple any of the components together. The bus can include any known interconnect, such as a multi-point branch bus, mesh interconnect, ring interconnect, point-to-point interconnect, serial interconnect, parallel bus, coherence (e.g., cache coherence) bus, hierarchical protocol architecture, differential bus, and emitter transceiver logic (GTL) bus. In various embodiments, the integrated I / O subsystem includes point-to-point multiplexing logic between various components of system 100, such as core 114, memory controller 116, I / O controller 112, integrated I / O devices, direct memory access (DMA) logic (not shown), etc. In various embodiments, the components of computer system 100 can be coupled together through one or more networks including any number of intermediary network nodes (such as routers, switches, or other computing devices). For example, a computing host (e.g., CPU 102) and storage device 106 can be coupled via network communication.

[0040] Although not depicted, system 100 may use a battery and / or power outlet connector for receiving power, as well as an associated system, a display for outputting data provided by CPU 102, or a network interface allowing CPU 102 to communicate over a network. In various embodiments, the battery, power outlet connector, display, and / or network interface may be communicatively coupled to CPU 102. Other power sources, such as renewable energy sources (e.g., solar or motion-based energy), may be used.

[0041] Figure 2 The diagram illustrates a block diagram of components of a computer system 200 implementing an operating system-based cache according to certain embodiments. System 200 may include any of the components of system 100. Various components of system 200 (e.g., virtual file system 204, file system 206, volatile page cache manager 208, block layer 210, storage cache layer 212, and storage device drivers 214 and 216) may include logic (e.g., software modules) implemented by operating system 122A, which may have any suitable characteristics of operating system 122.

[0042] In the depicted embodiment, application 124 issues a read or write system call 202. This system call may specify any appropriate information identifying the data, such as a file descriptor identifying the file to be accessed (in some cases this may include the file's path and / or name), the amount to be read or written (e.g., the number of bytes), the offset into the file (e.g., based on bytes from the beginning of the file), a buffer in which the read data is placed or the write data is stored, or other appropriate data associated with the data to be read or written.

[0043] System call 202 is received by virtual file system 204. Virtual file system 204 can be an abstraction of file system 206, allowing the application to generate system calls without relying on formatting requests from any of the many file systems that can be implemented by the operating system. If multiple file systems are implemented by operating system 122A, virtual file system 204 can determine the appropriate file system 206 to which the system call should be sent. Virtual file system 204 can format the system call in a manner compatible with the specific file system 206 to which the system call is sent.

[0044] File system 206 can represent any suitable file system, such as File Allocation Table (FAT), New Technology File System (NTFS), Resilient File System (ReFS), HFS+, Native Linux File System, ISOFS, or other suitable file systems. Generally, a file system makes stored data visible to applications or users (e.g., by organizing storage using hierarchical namespaces). A file system can manage access to both the content of files and the metadata about those files.

[0045] The file system 206 can invoke the page cache application programming interface (API) based on received system calls. In other embodiments, the virtual file system can directly invoke the page cache API based on received system calls (such invocations are handled by...). Figure 2 and 3 The dashed line between the virtual file system 204 and the volatile page cache managers 208 and 308 indicates this. API calls can include any of the information described above, such as that included in or derived from system calls. In one embodiment, an API call includes a file identifier (such as an inode or other similar identifier used in the Linux operating system), a file offset, and a number of bytes. The API call is sent to the volatile page cache manager 208, which determines whether the requested data is stored in the volatile page cache 128. The volatile page cache manager 208 can maintain a record of the data stored in the volatile page cache 128 and the state of such data.

[0046] In the case of a read system call, if the requested data is stored in volatile page cache 128, the data is provided to the requesting application (e.g., volatile page cache manager 208 may send a request for data to volatile system memory device 108 via volatile memory controller 118). If the requested data is not in volatile page cache 128, volatile page cache manager 208 notifies file system 206 of this. The file system then determines one or more LBAs corresponding to the data specified in system call 202. For example, the file system 206 may map file descriptors and offsets to LBAs.

[0047] One or more LBAs are passed to block layer 210. In one particular embodiment, the one or more LBAs determined by file system 206 may be relative LBAs (e.g., file system 206 may not know one or more other partitions on storage device 106 and therefore the determined LBAs may be specific to the partitions associated with the file system). Block layer 210 is aware of the other partitions on storage device 106 and can interpret the determined LBAs to one or more absolute LBAs. In some embodiments, block layer 210 may submit a request with one or more absolute LBAs to an I / O scheduler that aggregates similar requests before sending aggregated requests to storage cache layer 212. Storage cache layer 212 determines whether storage cache device 218 (e.g., an SSD or another storage device faster than storage device 106) has cached data corresponding to the determined LBAs. If storage cache device 218 currently caches data, storage cache layer 212 can send a request to storage device driver 216 to retrieve the data, and storage device driver 216 can send a request for the data to storage cache device 218 (e.g., via a controller, such as I / O controller 112). If storage cache device 218 does not have cached data, storage cache layer 212 sends a request for data stored at the determined LBA(one or more) to storage device driver 214, which then requests the data from storage device 106 (e.g., via I / O controller 112). The data is then cached in the storage cache device. In either case, data can be sent to volatile page cache 128 for storage therein (e.g., via direct memory access (DMA) operation) so that processor 111 can access the data from volatile page cache 128.

[0048] In the case of a write system call, as a result of system call 202, corresponding (though not exactly the same) operations can be performed, and data can be written to any one or more of the volatile page cache 128, storage cache device 218, and / or storage device 106. In one particular embodiment, the write system call writes data to the volatile page cache 128 or the persistent page cache 136, and the operating system asynchronously flushes the discarded page cache pages to storage device 106. Therefore, completing the write system call itself does not necessarily guarantee that the data is persistent (indeed, if the data is only stored in the volatile page cache 128, the data is not persistent). To ensure persistence, the application can issue additional system calls (e.g., fsync or msync) to instruct the operating system to synchronously flush discarded pages from the page cache to storage device 106. When data is written to the volatile page cache 128, this includes flushing the data to storage device 106. When data is written to persistent page cache 136, such system calls may simply involve flushing data from one or more CPU caches (e.g., L1 cache, L2 cache, LLC, etc.), followed by updating metadata to reflect that the data is persistent and may not necessarily cause the data to be synchronously flushed to storage device 106 (although in certain embodiments, such data is flushed to storage device 106 in response to these system calls).

[0049] Figure 3 The illustration shows a block diagram of components of a computer system 300 implementing a persistent page cache 136 according to certain embodiments. System 300 may include any of the components of system 100 or 200. The various components of system 300 are implemented by an operating system 122B (including a volatile page cache manager 308 and a persistent page cache manager 312), which may have any suitable features of other operating systems described herein.

[0050] In the depicted embodiment, the storage cache device 218 has been omitted because the persistent page cache 136 can provide persistent storage for cached data that is not directly addressable by the processor 111. Figure 2As in a system where read or write system call 202 can cause file system 206 to send a page cache API call to volatile page cache manager 308 (which may include any of the features of volatile page cache manager 208). However, volatile page cache manager 308 includes page cache selection and forwarding logic 310 operable to determine whether the API call represents a request for volatile page cache 128 or persistent page cache 136. If the request is for volatile page cache 128, volatile page cache manager 308 serves the request (e.g., by determining whether the requested data is stored in volatile page cache 128 and either requesting data from volatile page cache 128 or providing file system 206 with an indication that the data is not stored in volatile page cache 128). If the request is for persistent page cache 136, logic 310 forwards the request to persistent page cache manager 312. The persistent page cache manager 312 can perform functions similar to those of the volatile page cache manager but with respect to the persistent page cache 136. The persistent page cache manager 312 can service received requests (e.g., by determining whether the requested data is stored in the persistent page cache 136 and / or requesting data from the persistent page cache 136, or, for example, by providing an indication to the file system 206 via logic 310 that the data is not stored in the persistent page cache 136).

[0051] If the data is not stored in the selected page cache, then (in conjunction with the above) Figure 2 (In a similar manner to the description) data is requested from storage device 106. The requested data is then written to the selected page cache, where processor 111 can access it (e.g., via a load instruction) and the requested data is provided to application 124.

[0052] In a particular embodiment, persistent page cache 136 may include a persistent version of the kernel data structure of volatile page cache 128. As an example only, persistent page cache 136 may include a persistent radix tree. In one particular embodiment, an object cache (slab) allocator (used by operating system 122 to manage volatile memory) manages volatile page cache 128 but not persistent page cache 136. In another embodiment, a single allocator may manage both volatile page cache 128 and persistent page cache 136.

[0053] Because almost all existing file systems utilize page caching, these file systems can be compatible with System 300 with minimal to no changes to the file system itself, although changes can be made to the operating system's memory management system to accommodate the address space of the additional page cache (i.e., persistent page cache 136). For example, the operating system 122B can manage a file mapping table that includes a bit for each file mapping indicating whether the corresponding file should be cached in volatile page cache 128 or persistent page cache 136. When determining whether an API call application is forwarded to persistent page cache manager 312 or served by volatile page cache manager 308, logic 310 (or other selection logic described below) can access the appropriate entry to determine the value of that bit.

[0054] Because in some embodiments persistent memory 134 may have lower performance than volatile memory 126 (e.g., DRAM), it may be advantageous to cache some files in volatile page cache 128 and others in persistent page cache 136. Operating system 122 (or any of its variants described herein) may support selective caching of files in either volatile page cache 128 or persistent page cache 136. In one example, the decision to cache in persistent page cache 136 may be based on prompts from the application (e.g., flags received in system calls such as file open() or fadvise()). In another example, OS 122 may make the determination based on heuristics. For example, files opened for writing or boot-time files may be cached in persistent page cache 136. As another example, OS 122 may initially cache files in persistent page cache 136 and track file cache hit rates. If the hit rate increases beyond a certain threshold, the file may be additionally or alternatively cached in the volatile page cache 128 to improve access time. In other embodiments, instead of selecting page caches on a per-file basis, the entire file system may be designated for caching in the persistent page cache 136. For example, when a disk or a partition of a disk has a persistent caching option installed, all address mappings of the file structure read from that disk can be marked with a persistent flag, thereby prompting the file to be cached in the persistent page cache 136 (when cached).

[0055] Figure 4 The figure shows a block diagram of components of a computer system 400 implementing a persistent memory file system 404 and a persistent page cache 136 according to certain embodiments. Figure 4The illustration shows a block diagram of components of a computer system implementing a persistent page cache according to certain embodiments. System 400 may include any of the components of system 100 or other systems described herein. The various components of system 400 are implemented by an operating system 122C (including a persistent memory file system 404), which may have any suitable features of any of the operating systems described herein.

[0056] As in Figure 2 In the system, a read or write system call can result in the system call being passed to file system 206A. This file system can have any suitable characteristics of file system 206. File system 206A may additionally include file system selection and forwarding logic 402, operable to determine whether the system call represents a request for volatile page cache 128 or persistent page cache 136. If the request is for volatile page cache 128, logic 402 allows file system 206A to service the request (e.g., in a manner similar to that described above). If the request is for persistent page cache 136, logic 402 can make an API call to persistent storage file system 404. This API call can include any suitable parameters from or derived from system call 202. In a particular embodiment, the API call is a file system-cached API call or a similar API call as used in Linux-based operating systems.

[0057] The persistent memory file system 404 is any suitable persistent memory-aware file system, such as a file system implementing the functionality of a persistent memory file system (PMFS), a Linux-based DAX-EXT4 or DAX-XFS file system, a Windows-based DAS or DAX-mode NTFS file system, or other suitable file systems. Traditional file systems are configured to check page tables before accessing the storage device. In various embodiments, a persistent memory-aware file system is configured to perform reads and writes directly to the storage device (i.e., without first checking copies of data in the page cache). Therefore, the PM file system 404 can be configured to create a persistent page cache 136 that is directly accessed upon a data access request (without first checking a traditional page cache, such as a volatile page cache 128). In one particular embodiment, the persistent memory file system 404 is configured to send requests to the persistent page cache 136 but not to the volatile page cache 128.

[0058] When PM file system 404 receives an API call, persistent page cache manager 406 can service the request (e.g., by determining whether the requested data is stored in persistent page cache 136 and or requesting data from persistent page cache 136 or, for example, by providing an indication to file system 206A via logic 402 that the data is not stored in persistent page cache 136).

[0059] When file system 206A receives a system call indicating a request for volatile page cache 128, file system 206A can make an API call to volatile page cache manager 208, and volatile page cache manager 208 can service the request (e.g., by determining whether the requested data is stored in volatile page cache 128 and / or requesting data from volatile page cache 128 or providing an indication to file system 206 that the data is not stored in volatile page cache 128). In various embodiments, the operating system may cache stored data in both volatile page cache 128 and persistent page cache 136. In one particular embodiment, if it is determined that volatile page cache 128 does not contain the requested data, the file system (e.g., any of the file systems described herein) can make an API call to persistent page cache manager to determine whether persistent page cache 136 contains the data.

[0060] Regardless of the page cache being checked, when file system 206A receives an indication that data is not stored in the selected page cache (or in some embodiments, an indication that data is not stored in either page cache), it can request data from storage device 106 and then store that data in the selected page cache for retrieval by processor 111.

[0061] In system 400, the PM file system 404 is effectively used as a cache for file system 206A. Therefore, file system 206A is modified to use the PM file system 404 as a page cache (in place of volatile page cache 128) for certain data. When the PM file system 404 attempts to access data, it can bypass volatile page cache 128 and attempt to access data in persistent page cache 136. In various embodiments, the application is unaware of the PM file system 404 and operates under the assumption that file system 206A handles all read and write system calls. The PM file system 404 can directly access persistent page cache 136 (e.g., without going through the device driver and block layer).

[0062] Figure 5The diagram illustrates a block diagram of components of a computer system 500 implementing a persistent storage file system intermediary layer 502 and a persistent page cache 136 according to certain embodiments. System 500 may include components of system 100 or any of the other systems described herein. Various components of system 500 are implemented by an operating system 122D (including the persistent storage file system intermediary layer 502), which may have any suitable characteristics of any of the operating systems described herein.

[0063] The intermediary layer 502 intercepts requests sent to the file system 206 (e.g., by application 124 and / or virtual file system 204). The intermediary layer 502 determines whether the request relates to a file to be cached in persistent page cache 136 or a file to be cached in volatile page cache 128. If the request relates to a file marked as cached by volatile page cache 128, the request is allowed to pass through the intermediary layer 502 to the file system 206, where it is processed in a manner similar to that described above. If the request relates to a file marked as cached by persistent page cache 136, the intermediary layer 502 redirects the request to PM file system 404. In some embodiments, the intermediary layer 502 may also reformat the request into a format compatible with PM file system 404. The persistent page cache manager 406 then serves the request in a manner similar to that described above. If the persistent page cache 136 does not contain the requested data, the PM file system 404 notifies the intermediary layer 502 and the file system 206 makes a request to copy the data from the storage device 106 to the persistent page cache 136. The request from the intermediary layer can also instruct the file system not to check the volatile page cache before accessing the storage device 106 (e.g., using DIRECTI / O).

[0064] In one particular embodiment, instead of determining whether to pass the intercepted system call to file system 206 or redirect the call (e.g., via an API call) to PM file system 404, the intermediary layer 502 can default to making an API call to PM file system 404. If persistent page cache manager 406 determines that the data is not in persistent page cache 136, it can notify the intermediary layer 502, and the intermediary layer can then pass the system call to file system 206 for processing. This effectively allows the intermediary layer to present the operating system and applications with a new persistent memory file system that is the same size as storage device 106 by caching the data in persistent memory file system 404.

[0065] In one particular embodiment, a filter driver of the operating system 122D (e.g., some Windows-based operating systems provide a filter driver that can run on top of the file system) can be used to implement at least a portion of the intermediate layer 502. Thus, in one example, the filter driver can run on top of NTFS to implement system 500 without requiring any significant modifications to NTFS.

[0066] Figure 6 The illustration shows an example flow 600 according to certain embodiments for providing data from a page cache to a processor 111. Various operations of flow 600 can be performed by any suitable logic of system 100, such as CPU 102, volatile page cache 128, persistent page cache 136, or storage device 106.

[0067] At 602, for example, a data request is received from an application executed by processor 111. At 604, a determination is made as to whether the data is associated with volatile page cache 128 or persistent page cache 136. As an example, a table mapping files to page caches can be accessed to determine which page cache to specify to cache the data of the file referenced by the data request.

[0068] If the volatile page cache is associated with data, a determination is made at 606 as to whether the requested data is stored in the volatile page cache. If the volatile page cache stores the data, the data is provided to the processor from the volatile page cache at 608. The data can be provided in any suitable manner. As an example only, the data can be placed on the bus by the volatile system memory device 108 and copied into a register of the processor 111. If the data is not in the volatile page cache, the LBA corresponding to the data is determined at 610 (e.g., based on the file descriptor and offset of the data request) and a request with the LBA is sent to the storage device. At 612, the requested data is copied from the storage device to the volatile page cache and then provided to the processor at 608.

[0069] If the persistent page cache is associated with data, a determination is made at 614 as to whether the requested data is stored in the persistent page cache. If the persistent page cache stores the data, the data is provided to the processor from the persistent page cache at 616. The data can be provided in any suitable manner. As an example only, the data can be placed on the bus by the persistent system memory device 110 and copied into a register of the processor 111. If the data is not in the persistent page cache, the LBA corresponding to the data is determined at 618 (e.g., based on the file descriptor and offset of the data request) and a request with the LBA is sent to the storage device. At 620, the requested data is copied from the storage device to the persistent page cache and then provided to the processor at 616.

[0070] Figure 6 The processes described herein are merely representations of operations that may occur in a particular embodiment. In other embodiments, additional operations may be performed by components of system 100. Various embodiments of this disclosure are contemplated for any suitable signaling mechanism used to accomplish the functions described herein. Figure 6 Some of the operations illustrated in the diagram may be repeated, combined, modified, or deleted. Furthermore, the operations may be performed in any suitable order without departing from the scope of the particular embodiment.

[0071] Design can go through various stages from creation to simulation to manufacturing. The data representing the design can be presented in many ways. First, if useful in simulation, the hardware can be represented using a Hardware Description Language (HDL) or another functional description language. Additionally, circuit-level models with logic and / or transistor gates can be generated at certain stages of the design process. Furthermore, at some stage, most of the design reaches the data level, representing the physical placement of the various devices in a hardware model. In the case of using conventional semiconductor manufacturing techniques, the data representing the hardware model can be data specifying the presence or absence of various features on different mask layers for the masks used to produce integrated circuits. In some implementations, such data can be stored in database file formats such as Graphical Data System II (GDS II), Open Art System Exchange Standard (OASIS), or similar formats.

[0072] In some implementations, among other examples, software-based hardware models and HDL and other functional description language objects may include Register Transfer Language (RTL) files. Such objects may be machine-resolvable, enabling design tools to accept HDL objects (or models), parse the HDL objects for the attributes of the hardware, and determine physical circuitry and / or on-chip layout based on the objects. The output of the design tools can be used to manufacture the physical devices. For example, the design tools may determine the configuration of individual hardware and / or firmware elements based on HDL objects, in addition to other attributes to be implemented to realize the system modeled in the HDL object, such as bus width, registers (including size and type), memory blocks, physical link paths, and structural topology. The design tools may include tools for determining the topology and structural configuration of the system-on-chip (SoC) and other hardware devices. In some examples, HDL objects may be used as the basis for developing models and design documents that can be used by manufacturing equipment to manufacture the hardware. Indeed, the HDL file itself may be provided as input to manufacturing system software to facilitate the manufacture of the hardware.

[0073] In any representation of the design, data representing the design may be stored in any form of machine-readable medium. Memory or magnetic or optical storage devices (such as disks) may be machine-readable media used to store information transmitted via light or radio waves that are modulated or otherwise generated to transmit such information. When an electrical carrier signal indicating or carrying code or the design is transmitted, a new copy is made to the extent that the electrical signal is copied, buffered, or retransmitted. Therefore, a communications provider or network provider may store terms (such as information encoded in a carrier signal) on a tangible machine-readable medium, thereby embodying the techniques of embodiments of this disclosure.

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

[0075] Therefore, one or more aspects of at least one embodiment can be implemented by representational instructions stored on a machine-readable medium, which represent various logic within a processor and, when read by a machine, cause the machine manufacturing logic to perform the techniques described herein. Such representations (often referred to as “IP cores”) can be stored on a non-transitory tangible machine-readable medium and supplied to various customers or manufacturing facilities for loading into the manufacturing machine or processor of the manufacturing logic.

[0076] Embodiments of the mechanisms disclosed herein may be implemented in hardware, software, firmware, or a combination of such implementations. Embodiments of this disclosure may be implemented as computer programs or program code executable on a programmable system including at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0077] Program code can be applied to input instructions to perform the functions described herein and generate output information. The output information can be applied to one or more output devices in known manners. For the purposes of this application, the processing system includes any system having a processor, such as, for example, a digital signal processor (DSP), a microcontroller, an application-specific integrated circuit (ASIC), or a microprocessor.

[0078] The program code can be implemented in a high-level programming language or an object-oriented programming language to communicate with the processing system. If needed, the program code can also be implemented in assembly or machine language. In fact, the mechanisms described herein are not limited to any particular programming language. In various embodiments, the language can be a compiled or interpreted language.

[0079] Embodiments of the methods, hardware, software, firmware, or code described above can be implemented via instructions or code stored on a machine-accessible, machine-readable, computer-accessible, or computer-readable medium executable by processing elements (or otherwise accessible). Non-transitory machine-accessible / readable media include any mechanism that provides (i.e., stores and / or transmits) information in a machine-readable form, such as a computer or electronic system. For example, non-transitory machine-accessible media include random access memory (RAM), such as static RAM (SRAM) or dynamic RAM (DRAM); ROM; magnetic or optical storage media; flash memory devices; electrical storage devices; optical storage devices; acoustic storage devices; other forms of storage devices for retaining information received from transient (propagating) signals (e.g., carrier waves, infrared signals, digital signals), etc., to be distinguished from non-transitory media from which information may be received.

[0080] Instructions used to program logic to execute embodiments of this disclosure can be stored in memory (such as DRAM, cache, flash memory, or other storage devices) within the system. Furthermore, instructions can be distributed via a network or through other computer-readable media. Therefore, machine-readable media can include any mechanism for storing or transmitting information in a machine-readable (e.g., computer-readable) form, but is not limited to floppy disks, optical disks, compact discs, read-only memory (CD-ROM), and magneto-optical disks, read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic or optical cards, flash memory, or tangible machine-readable storage devices used in information transmission via the Internet through electrical, optical, acoustic, or other forms of propagation signals (e.g., carrier waves, infrared signals, digital signals, etc.). Therefore, computer-readable media includes any type of tangible machine-readable medium suitable for storing or transmitting electronic instructions or information in a machine-readable (e.g., computer-readable) form.

[0081] Logic can be used to implement any of the various components of the system depicted in the figure, such as CPU 102, external I / O controller 104, storage device 106, system memory devices 108 and 110, other components or sub-components described herein, or any of them. "Logic" can refer to hardware, firmware, software, and / or combinations of each used to perform one or more functions. As an example, logic may include hardware (such as a microcontroller or processor) associated with a non-transitory medium to store code adapted for execution by that microcontroller or processor. Thus, in one embodiment, a reference to logic refers to hardware specifically configured to identify and / or execute code to be held on a non-transitory medium. Furthermore, in another embodiment, the use of logic refers to a non-transitory medium comprising code specifically adapted for execution by a microcontroller to perform a predetermined operation. And as can be inferred, in yet another embodiment, the term logic (in this example) may refer to a combination of hardware and non-transitory medium. In various embodiments, logic may include a microprocessor or other processing element operable to execute software instructions, discrete logic (such as an application-specific integrated circuit (ASIC)), programmable logic devices (such as a field-programmable gate array (FPGA)), a memory device containing instructions, a combination of logic devices (e.g., as would be found on a printed circuit board), or other suitable hardware and / or software. Logic may include one or more gates or other circuit components that can be implemented, for example, by transistors. In some embodiments, logic may also be entirely embodied as software. Software may be embodied as software packages, code, instructions, instruction sets, and / or data recorded on a non-transitory computer-readable storage medium. Firmware may be embodied as code, instructions, or instruction sets and / or data hard-coded (e.g., non-volatile) in a memory device. Often, the logical boundaries illustrated as separate are often variable and potentially overlapping. For example, first and second logic may share hardware, software, firmware, or a combination thereof while potentially maintaining a separate hardware, software, or firmware.

[0082] In one embodiment, the phrase 'used to' or 'configured to' refers to arranging, placing, manufacturing, providing for sale, inputting, and / or designing a device, hardware, logic, or element to perform a specified or defined task. In this example, if no operating device or element is designed, coupled, and / or interconnected to perform the specified task, then the non-operating device or element is still 'configured to' perform the specified task. As a purely illustrative example, a logic gate can provide 0 or 1 during operation. However, a logic gate 'configured to' provide an enable signal to a clock does not include every potential logic gate that can provide 1 or 0. Instead, the logic gate is a logic gate coupled in a way that the 1 or 0 output is used to enable the clock during operation. To reiterate, the use of the term 'configured to' does not require operation but rather serves as a substitute for focusing on the potential state of a device, hardware, and / or element, in which the device, hardware, and / or element is designed to perform a specific task while it is operating.

[0083] Furthermore, in one embodiment, the phrases 'capable of / can be used with' and / or 'operable for use with' refer to a device, logic, hardware, and / or element designed in such a way that it can be used in a specific manner. In one embodiment, as noted above, the use of 'used with, can be used with, or is operable for use with' refers to a potential state of a device, logic, hardware, and / or element where the device, logic, hardware, and / or element is not operational but designed in such a way that it can be used in a specific manner.

[0084] As used herein, values ​​include any known representation of numbers, states, logical states, or binary logical states. Often, the use of logic levels, logic values, or multiple logic values ​​is also referred to as 1 and 0, which simply represent binary logical states. For example, 1 represents a high logic level and 0 represents a low logic level. In one embodiment, a memory cell such as a transistor or flash unit may be able to hold a single logic value or multiple logic values. However, other representations of values ​​are already used in computer systems. For example, a decimal tens can also be represented as the binary value of 1010 and the hexadecimal letter A. Therefore, values ​​include any representation of information that can be held in a computer system.

[0085] Furthermore, a state can be represented by a value or parts of a value. As an example, a first value such as a logical one can represent a default or initial state, while a second value such as logical zero can represent a non-default state. Additionally, in one embodiment, the terms reset and set refer to default and updated values ​​or states, respectively. For example, a default value potentially includes a high logical value (i.e., reset), while an updated value potentially includes a low logical value (i.e., set). It should be noted that any combination of values ​​can be used to represent any number of states.

[0086] In at least one embodiment, an apparatus includes a memory for storing executable instructions of an operating system; and a processor for recognizing a request for data from an application; determining whether a persistent page cache stores a copy of data, wherein the persistent page cache is directly addressable by the processor and is used to cache data from storage devices that are not directly addressable by the processor; and accessing the data from the persistent page cache.

[0087] In one embodiment, the processor is configured to identify a request for second data from a second application; determine whether a volatile page cache stores a copy of the data, wherein the volatile page cache is directly addressable by the processor and used to cache data on a storage device; and access the data from the volatile page cache. In one embodiment, the processor is configured to implement a volatile page cache manager, which determines whether a file containing the data is marked as cached in a persistent page cache; and send a request for the data to the persistent page cache manager. In one embodiment, the processor is configured to implement a first file system of the operating system, wherein the first file system determines whether a file containing the data is marked as cached in a persistent page cache or a volatile page cache; and in response to determining that the file is marked as cached in a persistent page cache, send a request for the data to a second file system. In one embodiment, the processor is configured to implement a first file system for sending a data request to a volatile page cache; implement a second file system for sending a data request to a persistent page cache; and implement an intermediary layer for intercepting data requests sent to the first file system and conveying the data request to the second file system. In one embodiment, the request for data includes a file descriptor. In one embodiment, the processor is configured to send a request to the storage device to copy the data to the persistent page cache when it determines that the persistent page cache does not store a copy of the data. In one embodiment, the processor is configured to interpret the file descriptor and offset of the data request into a logical block address and send the logical block address to the storage device in the request to the storage device. In one embodiment, the volatile page cache is to be stored in volatile memory, which is further used to store application code and application data. In one embodiment, the persistent page cache is to be stored in 3D cross-point memory. In one embodiment, the processor is configured to determine whether to cache the data in the volatile page cache or the persistent page cache based on at least one of the following: a prompt from the application that issued the system call referencing the data; whether the data is open for writing; whether the data is required for startup; or whether the data is file data or metadata. In one embodiment, the processor is configured to update the metadata in the persistent page cache to mark the obsolete data as persistent when a request for synchronization of obsolete data to the persistent page cache is received.

[0088] In at least one embodiment, a method includes identifying a request for data from an application; determining whether a persistent page cache stores a copy of data, wherein the persistent page cache is directly addressable by a processor and is used to cache data from storage devices that are not directly addressable by a processor; and accessing the data from the persistent page cache.

[0089] In one embodiment, the method further includes identifying a request for second data from a second application; determining whether a volatile page cache stores a copy of the data, wherein the volatile page cache is directly addressable by the processor and used to cache data on a storage device; and accessing the data from the volatile page cache. In one embodiment, the method further includes implementing a volatile page cache manager to determine whether a file containing the data is marked as cached in a persistent page cache; and sending a request for the data to the persistent page cache manager. In one embodiment, the method further includes implementing a first file system of the operating system to determine whether a file containing the data is marked as cached in a persistent page cache or a volatile page cache; and in response to determining that the file is marked as cached in a persistent page cache, sending a request for the data to a second file system. In one embodiment, the method further includes implementing a first file system for sending a data request to a volatile page cache; implementing a second file system for sending a data request to a persistent page cache; and implementing an intermediary layer for intercepting data requests sent to the first file system and conveying the data request to the second file system. In one embodiment, the request for data includes a file descriptor. In one embodiment, the method further includes sending a request to the storage device to copy the data to the persistent page cache when it is determined that the persistent page cache does not store a copy of the data. In one embodiment, the method further includes interpreting the file descriptor and offset of the request for the data into a logical block address and sending the logical block address to the storage device in the request to the storage device. In one embodiment, the volatile page cache is to be stored in volatile memory, which is further used to store application code and application data. In one embodiment, the persistent page cache is to be stored in 3D cross-point memory. In one embodiment, the method further includes determining whether to cache the data in the volatile page cache or the persistent page cache based on at least one of the following: a prompt from the application that issued the system call referencing the data; whether the data is open for writing; whether the data is required for startup; or whether the data is file data or metadata. In one embodiment, the method further includes updating the metadata in the persistent page cache to mark the obsolete data as persistent when a request for synchronizing obsolete data to the persistent page cache is received.

[0090] In at least one embodiment, a non-transitory machine-readable storage medium includes instructions stored thereon that, when executed by a processor, cause the processor to recognize a request for data from an application; determine whether a persistent page cache stores a copy of data, wherein the persistent page cache is directly addressable by the processor and is used to cache data from storage devices that are not directly addressable by the processor; and access the data from the persistent page cache.

[0091] In one embodiment, when executed, the instructions further cause the processor to recognize a request for second data from a second application; determine whether a copy of the data is stored in a volatile page cache, wherein the volatile page cache is directly addressable by the processor and used to cache data in a storage device; and access the data from the volatile page cache. In one embodiment, when executed, the instructions further cause the processor to implement a volatile page cache manager, which determines whether the file containing the data is marked as cached in a persistent page cache; and send a request for the data to the persistent page cache manager. In one embodiment, when executed, the instructions further cause the processor to implement a first file system of the operating system, wherein the first file system determines whether the file containing the data is marked as cached in a persistent page cache or a volatile page cache; and in response to determining that the file is marked as cached in a persistent page cache, send a request for the data to a second file system. In one embodiment, when executed, the instructions are used to further cause the processor to implement a first file system for sending data requests to a volatile page cache; implement a second file system for sending data requests to a persistent page cache; and implement an intermediary layer for intercepting data requests sent to the first file system and conveying the data requests to the second file system.

[0092] In at least one embodiment, a computer system includes: volatile memory for storing volatile page caches; persistent memory for storing persistent page caches; and a processor for identifying a request for data from an application; determining whether the persistent page cache stores a copy of data, wherein the persistent page cache is directly addressable by the processor and is used to cache data from storage devices that are not directly addressable by the processor; and accessing the data from the persistent page cache.

[0093] In one embodiment, the processor is configured to identify a request for second data from a second application; determine whether a volatile page cache stores a copy of the data, wherein the volatile page cache is directly addressable by the processor and used to cache data from a storage device; and access the data from the volatile page cache. In one embodiment, the volatile page cache is to be stored in volatile memory, which is further used to store application code and application data. In one embodiment, the computer system further includes a storage device. In one embodiment, the computer system further includes one or more of the following: a battery communicatively coupled to the processor, a display communicatively coupled to the processor, or a network interface communicatively coupled to the processor.

[0094] In at least one embodiment, a system includes: components for identifying a request for data from an application; components for determining whether a persistent page cache stores a copy of data, wherein the persistent page cache is directly addressable by a processor and is used to cache data from storage devices that are not directly addressable by a processor; and components for accessing data from the persistent page cache.

[0095] In one embodiment, the system further includes: components for identifying a request for second data from a second application; components for determining whether a copy of the data is stored in a volatile page cache, wherein the volatile page cache is directly addressable by the processor and is used to cache data in a storage device; and components for accessing the data from the volatile page cache.

[0096] In one embodiment, the system further includes components for implementing a volatile page cache manager to determine whether a file containing the data is marked as cached in a persistent page cache; and components for sending a request for data to the persistent page cache manager. In one embodiment, the system further includes components for implementing a first file system of an operating system, wherein the first file system is used to determine whether a file containing the data is marked as cached in a persistent page cache or a volatile page cache; and in response to determining that the file is marked as cached in a persistent page cache, sending a request for data to a second file system. In one embodiment, the system further includes components for implementing a first file system for sending a data request to a volatile page cache; components for implementing a second file system for sending a data request to a persistent page cache; and components for implementing an intermediary layer for intercepting data requests sent to the first file system and conveying the data request to the second file system.

[0097] References to "one embodiment" or "embodiment" throughout this specification mean that a particular feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment of this disclosure. Therefore, the appearance of the phrase "in one embodiment" or "in an embodiment" throughout this specification does not necessarily all refer to the same embodiment. Furthermore, that particular feature, structure, or characteristic may be combined in any suitable manner in one or more embodiments.

[0098] In the foregoing specification, a detailed description has been given with reference to specific exemplary embodiments. However, it will be apparent that various modifications and changes can be made thereto without departing from the broader spirit and scope of this disclosure as set forth in the appended claims. Accordingly, this specification and drawings should be regarded as illustrative rather than restrictive. Furthermore, the foregoing use of the language of embodiments and other exemplary embodiments does not necessarily refer to the same embodiment or the same example, but may refer to different and distinct embodiments, as well as potentially identical embodiments.

Claims

1. An apparatus comprising: Memory used to store executable instructions of the operating system; and A processor is used to: Implement a first file system for sending data requests toward the volatile page cache; Implement a second file system for sending data requests toward the persistent page cache; Identify requests for the first data from the application; Determine whether a persistent page cache stores a copy of the first data, wherein the persistent page cache is directly addressable by the processor and is used to cache data from storage devices that are not directly addressable by the processor; and Access the first data from the persistent page cache.

2. The processor of claim 1, wherein the processor is configured to: Identify requests for second data from a second application; Determine whether a volatile page cache stores a copy of data, wherein the volatile page cache is directly addressable by the processor and used to cache data in storage devices; and Access data from the volatile page cache.

3. The processor according to any one of claims 1-2, wherein the processor is configured to: Implement a volatile page cache manager, which determines whether a file containing the data is marked as cached in the persistent page cache; and Send a request for data to the persistent page cache manager.

4. The processor according to any one of claims 1-2, wherein the processor is configured to implement a first file system of an operating system, wherein the first file system is configured to: Determine whether the file containing this data is marked as cached in the persistent page cache or the volatile page cache; and In response to determining that the file is marked as cached in the persistent page cache, a request for the data is sent to the second file system.

5. The processor according to any one of claims 1-2, wherein the processor is configured to: An intermediary layer is implemented to intercept data requests sent to the first file system and forward those requests to the second file system.

6. The processor of claim 1, wherein the processor is configured to determine whether to cache data in a volatile page cache or a persistent page cache based on at least one of the following: A prompt from the application that issued the system call referencing the data; Is this data open for writing? Is this data required for startup? Is this data file data or metadata? 7. The processor of claim 1, wherein the processor is configured to send a request to the storage device to copy the data to the persistent page cache when it is determined that the persistent page cache does not store a copy of the data.

8. The processor of claim 1, wherein the processor is configured to interpret the file descriptor and offset of the data request into a logical block address and send the logical block address to the storage device in the request for the storage device.

9. The processor of claim 1, wherein the volatile page cache is to be stored in volatile memory, the volatile memory being further used to store application code and application data.

10. The processor of claim 1, wherein the processor is configured to update the metadata in the persistent page cache to mark the obsolete data as persistent upon receiving a request for synchronization of obsolete data in the persistent page cache.

11. A method comprising: Implement a first file system for sending data requests toward the volatile page cache; Implement a second file system for sending data requests toward the persistent page cache; Identify requests for the first data from the application; Determine whether a persistent page cache stores a copy of the first data, wherein the persistent page cache is directly addressable by the processor and is used to cache data from storage devices that are not directly addressable by the processor; and Access the first data from the persistent page cache.

12. The method of claim 11, further comprising: Identify requests for second data from a second application; Determine whether a volatile page cache stores a copy of data, wherein the volatile page cache is directly addressable by the processor and used to cache data in storage devices; and Access data from the volatile page cache.

13. The method of claim 11, further comprising: Implement a volatile page cache manager, which is used to determine whether a file containing the data is marked as cached in the persistent page cache; as well as Send a request for data to the persistent page cache manager.

14. The method of claim 11, further comprising a first file system implementing an operating system, wherein the first file system is used to: Determine whether the file containing this data is marked as cached in the persistent page cache or the volatile page cache; and In response to determining that the file is marked as cached in the persistent page cache, a request for the data is sent to the second file system.

15. The method of claim 11, further comprising: An intermediary layer is implemented to intercept data requests sent to the first file system and forward those requests to the second file system.

16. The method of claim 11, wherein the request for data includes a file descriptor.

17. The method of claim 11, further comprising sending a request to the storage device to copy the data to the persistent page cache when it is determined that the persistent page cache does not store a copy of the data.

18. The method of claim 11, further comprising interpreting the file descriptor and offset of the data request into a logical block address and sending the logical block address to the storage device in the request for the storage device.

19. The method of claim 11, wherein the volatile page cache is to be stored in volatile memory, the volatile memory being further used to store application code and application data.

20. The method of claim 11, wherein the persistent page cache is to be stored in a 3D crosspoint memory.

21. A system comprising components for performing the method of any one of claims 11-20.

22. The system of claim 21, wherein the component includes machine-readable code that, when executed, causes the machine to perform one or more steps of the method of any one of claims 11-20.

23. A computer-readable medium having instructions thereon that, when executed, cause a computer device to perform the method according to any one of claims 11-20.

Images