Persistent memory controller for memory management and method of memory management

Abstract

A persistent memory controller for memory management and a method of memory management are provided. In one or more examples, the persistent memory controller includes: a metadata controller configured to generate metadata based on monitoring data in a volatile memory; a memory manager configured to generate a request for removing the data in the volatile memory based on the metadata; and a data controller configured to process the request based on the request being allowed to the data controller in response to a grant to the request based on request criteria.

Description

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 620,168, filed on Jan. 11, 2024, and U.S. Patent Application No. 18 / 616,153, filed on Mar. 25, 2024, which are hereby incorporated by reference for all purposes. Technical Field

[0002] This disclosure relates to a persistent memory controller for memory management and a method of memory management. Background Art

[0003] This background art section is only intended to provide context, and the disclosure of any concepts in this section does not constitute an admission that the concepts are prior art.

[0004] In some systems, memory may be moved from a first storage location to a second storage location. For some systems, moving large amounts of data may take a relatively long time to perform. The time taken to move data may increase system latency and reduce system efficiency. Additionally, based on the time taken to move data, delays may occur in system communications (such as delays in communication acknowledgments related to the successful movement of data). Further, data movement may consume a relatively large amount of energy, further reducing system efficiency. Such time delays typically result in increased system costs and limitations on storage capacity.

[0005] The above information disclosed in the background art section is only for enhancing the understanding of the background of the disclosure, and thus it may include information that does not constitute prior art. Summary of the Invention

[0006] In various embodiments, the systems and methods described herein include systems, methods, and apparatuses for low-latency global persistent flushing based on background eviction. In some aspects, the systems and methods described herein relate to a persistent memory controller for memory management, the persistent memory controller including: a metadata controller configured to generate metadata based on monitoring data in volatile memory; a memory manager configured to generate a request for removing the data in volatile memory based on the metadata; and a data controller configured to process the request based on an arbiter granting the request based on request criteria and allowing the request to proceed to the data controller.

[0007] In some aspects, the systems and methods described herein relate to a persistent memory controller, wherein the step of the data controller processing the request includes the data controller moving the data based on device idle time.

[0008] In some aspects, the systems and methods described herein relate to a persistent memory controller wherein request criteria is based on a priority of the request relative to a priority of a host request.

[0009] In some aspects, the systems and methods described herein relate to a persistent memory controller wherein the request criteria is based on a pattern of the data in volatile memory.

[0010] In some aspects, the systems and methods described herein relate to a persistent memory controller wherein the request criteria is based on at least one of: the age of the data in volatile memory, the heat of the data in volatile memory, or a selective process for selecting the request.

[0011] In some aspects, the systems and methods described herein relate to a persistent memory controller wherein the request criteria is based on a number of requests at the memory manager relative to a number of requests at the host.

[0012] In some aspects, the systems and methods described herein relate to a persistent memory controller wherein the request criteria is based on a frequency of requests at a memory manager relative to a frequency of requests at a host.

[0013] In some aspects, the systems and methods described herein relate to a persistent memory controller wherein the request criteria is based on a memory manager determining a busy status of a host.

[0014] In some aspects, the systems and methods described herein relate to a persistent memory controller, wherein the metadata includes at least one of the following items: a dirty state of the data in the volatile memory, an age of the data in the volatile memory, or register metadata including at least one of a dirty data count, a hot data count, a host request count, an eviction threshold, or a data temperature threshold.

[0015] In some aspects, the systems and methods described herein relate to a persistent memory controller wherein metadata describes the data in volatile memory.

[0016] In some aspects, the systems and methods described herein relate to a method for memory management via at least one of one or more processors, the method comprising: generating metadata based on monitoring data in a volatile memory; generating a request for removing the data in the volatile memory based on the metadata; and being allowed to go to a data controller to process the request in response to granting the request based on request criteria based on the request.

[0017] In some aspects, the systems and methods described herein relate to a method in which the step of processing the request includes moving data based on device idle time.

[0018] In some aspects, the systems and methods described herein relate to a method in which the request criteria are based on at least one of the following: the priority of the request relative to the priority of the host request, or the pattern of the data in volatile memory.

[0019] In some aspects, the systems and methods described herein relate to a method in which the request criteria are based on at least one of the following: the age of the data in volatile memory, or the heat of the data in volatile memory.

[0020] In some aspects, the systems and methods described herein relate to a method in which the request criteria are based on the number of requests at the memory manager relative to the number of requests at the host.

[0021] In some aspects, the systems and methods described herein relate to a method in which the request criteria are based on at least one of the following: the frequency of requests at the memory manager relative to the frequency of requests at the host, or determining that the host is in an idle state.

[0022] In some aspects, the systems and methods described herein relate to a method in which the metadata includes at least one of the following: the dirty state of the data in volatile memory, the age of the data in volatile memory, or register metadata including at least one of a dirty data count, a hot data count, a host request count, an eviction threshold, or a data heat threshold.

[0023] In some aspects, the systems and methods described herein relate to a non-transitory computer-readable medium storing code that includes instructions executable by at least one processor of a device to: generate metadata based on monitored data in volatile memory; generate a request to remove the data from volatile memory based on the metadata; and process the request based on the request being allowed to proceed to a data controller in response to permission of the request based on request criteria.

[0024] In some aspects, the systems and methods described herein relate to a non-transitory computer-readable medium in which the step of processing the request is based on further instructions executable by the at least one processor of the device to move the data during idle time of the device.

[0025] In some aspects, the systems and methods described herein relate to a non-transitory computer-readable medium, wherein a request criterion is based on at least one of the following: the priority of the request relative to the priority of a host request, the pattern of the data in volatile memory, the age of the data in volatile memory, or the heat of the data in volatile memory.

[0026] Disclosed is a computer-readable medium. The computer-readable medium may store instructions that, when executed by a computer, cause the computer to perform operations that are substantially the same as or similar to those further disclosed as described herein. Similarly, also disclosed are non-transitory computer-readable media, apparatuses, and systems for performing operations that are substantially the same as or similar to those described herein.

[0027] The systems and methods for background-eviction-based low-latency global persistence flushing (GPF) described herein include several advantages and benefits. For example, the systems and methods provide that: volatile data is dumped to a persistent storage device during device idle time (e.g., the idle time of a host system or a time of relatively low data traffic from a host system). Dumping data during device idle time significantly reduces GPF dump time and saves energy. Additionally, based on dumping volatile data to a persistent storage device during device idle time, responses to the host during the GPF phase are made in a timely manner, thus reducing system overhead. Based on the reduced dump energy consumed, the CXL PMEM storage capacity is increased (e.g., for NVMe server storage subsystem form factors, NVMe SSD form factors (such as E3.5, etc.)). BRIEF DESCRIPTION OF THE DRAWINGS

[0028] The above and other aspects of the present systems and methods will be better understood when read in view of the following drawings, in which like numerals indicate like or identical elements. Additionally, the drawings provided herein are for the purpose of illustrating specific embodiments only; other embodiments that may not be explicitly shown are not excluded from the scope of the present disclosure.

[0029] These and other features and advantages of the present disclosure will be appreciated and understood by reference to the specification, claims, and drawings.

[0030] Figure 1 An example system is shown in accordance with one or more embodiments as described herein.

[0031] Figure 2 shown in accordance with one or more embodiments as described herein Figure 1 of the details of the system.

[0032] Figure 3 An example system is shown in accordance with one or more embodiments as described herein.

[0033] Figure 4 Illustrates an example system in accordance with one or more embodiments described herein.

[0034] Figure 5 Depicts a flowchart illustrating an example method associated with the disclosed system in accordance with example embodiments described herein.

[0035] Figure 6 Depicts a flowchart illustrating an example method associated with the disclosed system in accordance with example embodiments described herein.

[0036] Figure 7 Depicts a flowchart illustrating an example method associated with the disclosed system in accordance with example embodiments described herein.

[0037] Figure 8 Depicts a flowchart illustrating an example method associated with the disclosed system in accordance with example embodiments described herein.

[0038] Figure 9 Depicts a flowchart illustrating an example method associated with the disclosed system in accordance with example embodiments described herein.

[0039] Figure 10 Depicts a flowchart illustrating an example method associated with the disclosed system in accordance with example embodiments described herein.

[0040] Figure 11 Depicts a flowchart illustrating an example method associated with the disclosed system in accordance with example embodiments described herein.

[0041] While the systems and methods are susceptible to various modifications and alternative forms, specific embodiments of the systems and methods are shown by way of example in the drawings and will be described herein. The drawings may not be to scale. However, it should be understood that the drawings and their detailed description are not intended to limit the systems and methods to the particular forms disclosed, but rather, are intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the systems and methods as defined by the appended claims. Detailed Description

[0042] In some systems, all data in volatile memory may be dumped to persistent memory (e.g., non-volatile flash memory) based on a given persistence flush trigger. However, transferring all data in volatile memory to persistent memory takes a relatively long time (e.g., 3 to 4 seconds for 16 GB of data). A given device may require a relatively large amount of energy to ensure that the data is successfully dumped to persistent memory. This process results in increased system latency, increased system cost, lower system efficiency, and limited persistent memory capacity.

[0043] Details of one or more embodiments of the subject matter described herein are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the subject matter will become apparent from the description, the drawings, and the claims.

[0044] Various embodiments of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all, embodiments are shown. In fact, the disclosure may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Unless otherwise indicated, the term "or" is used herein in its alternative and conjunctive sense. The terms "exemplary" and "example" are used for examples that do not indicate a level of quality. The same number always refers to the same element. Arrows in each of the drawings depict bidirectional data flow and / or bidirectional data flow capabilities. The terms "path", "route", and "way" are used interchangeably herein.

[0045] Embodiments of the present disclosure may be implemented in various ways, including as a computer program product that includes a manufactured article. The computer program product may include a non-transitory computer-readable storage medium that stores applications, programs, program components, scripts, source code, program code, object code, byte code, compiled code, interpreted code, machine code, executable instructions, and the like (also referred to herein as executable instructions, instructions for execution, computer program products, program code, and / or similar terms that may be used interchangeably herein). Such non-transitory computer-readable storage media include all computer-readable media (including volatile and non-volatile media).

[0046] In one embodiment, a non-volatile computer-readable storage medium may include a floppy disk, a flexible disk, a hard disk, solid state storage (SSS) (e.g., a solid state drive (SSD)), a solid state card (SSC), a solid state module (SSM), an enterprise flash drive, a magnetic tape, or any other non-transitory magnetic medium, etc. The non-volatile computer-readable storage medium may include a punched card, a paper tape, an optical mark sheet (or any other physical medium having a pattern of holes or other optically recognizable marks), a compact disc read only memory (CD-ROM), a rewritable compact disc (CD-RW), a digital versatile disc (DVD), a Blu-ray disc (BD), any other non-transitory optical medium, etc. Such a non-volatile computer-readable storage medium may include a read only memory (ROM), a programmable read only memory (PROM), an erasable programmable read only memory (EPROM), an electrically erasable programmable read only memory (EEPROM), flash memory (e.g., serial, NAND, NOR, etc.), a multimedia memory card (MMC), a secure digital (SD) memory card, a smart media card, a compact flash (CF) card, a memory stick, etc. In addition, the non-volatile computer-readable storage medium may include a conductive-bridging random access memory (CBRAM), a phase change random access memory (PRAM), a ferroelectric random access memory (FeRAM), a non-volatile random access memory (NVRAM), a magnetoresistive random access memory (MRAM), a resistive random access memory (RRAM), a silicon-oxide-nitride-oxide-silicon memory (SONOS), a floating junction gate random access memory (FJG RAM), a millipede memory, a racetrack memory, etc.

[0047] In one embodiment, the volatile computer-readable storage medium may include random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), fast page mode dynamic random access memory (FPM DRAM), extended data output dynamic random access memory (EDO DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), double data rate type two synchronous dynamic random access memory (DDR2 SDRAM), double data rate type three synchronous dynamic random access memory (DDR3 SDRAM), Rambus dynamic random access memory (RDRAM), two-transistor RAM (TTRAM), thyristor RAM (T-RAM), zero-capacitor (Z-RAM), Rambus in-line memory module (RIMM), dual in-line memory module (DIMM), single in-line memory module (SIMM), video random access memory (VRAM), cache memory (including various levels), flash memory, register memory, etc. It will be understood that in cases where an embodiment is described as using a computer-readable storage medium, other types of computer-readable storage media may be substituted for or used in addition to the computer-readable storage media described above.

[0048] As should be understood, various embodiments of the present disclosure may be implemented as a method, apparatus, system, computing device, computing entity, etc. Thus, embodiments of the present disclosure may take the form of an apparatus, system, computing device, computing entity, etc. that executes instructions stored on a computer-readable storage medium to perform specific steps or operations. Accordingly, embodiments of the present disclosure may take the form of a fully hardware embodiment, a fully computer program product embodiment, and / or an embodiment that includes a combination of a computer program product and hardware that executes specific steps or operations.

[0049] Embodiments of the present disclosure will be described below with reference to the block diagrams and flowcharts. Therefore, it should be understood that each block of the block diagrams and flowcharts can be implemented in the form of a computer program product, a complete hardware embodiment, a combination of hardware and computer program products, and / or a device, system, computing device, computing entity, etc. that executes instructions, operations, steps, and similar terms that can be used interchangeably (e.g., executable instructions, instructions for execution, program code, etc.) on a computer-readable storage medium. For example, the retrieval, loading, and execution of the code can be performed sequentially, such that one instruction is retrieved, loaded, and executed at a time. In some example embodiments, the retrieval, loading, and / or execution can be performed in parallel, such that multiple instructions are retrieved, loaded, and / or executed together. Thus, such embodiments can produce a specially configured machine that executes the steps or operations specified in the block diagrams and flowcharts. Therefore, the block diagrams and flowcharts support various combinations of embodiments for executing the specified instructions, operations, or steps.

[0050] The following description is presented to enable a person having ordinary skill in the art to make and use the subject matter disclosed herein and to incorporate the subject matter in the context of a particular application. While the following is directed to specific examples, other and further examples can be designed without departing from its basic scope.

[0051] Various modifications and various uses in different applications will be apparent to those skilled in the art, and the general principles defined herein can be applied to a wide range of embodiments. Therefore, the subject matter disclosed herein is not intended to be limited to the presented embodiments, but rather will conform to the broadest scope consistent with the principles and novel features disclosed herein.

[0052] In the provided description, numerous specific details are set forth in order to provide a more thorough understanding of the subject matter disclosed herein. However, it will be apparent to those skilled in the art that the subject matter disclosed herein can be practiced without necessarily being limited to these specific details. In other instances, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring the subject matter disclosed herein.

[0053] Unless otherwise expressly stated, all features disclosed in this specification (e.g., any appended claims, abstract, and drawings) can be replaced by alternative features serving the same, equivalent, or similar purpose. Therefore, unless otherwise expressly stated, each feature disclosed is only an example of a general series of equivalent or similar features.

[0054] Various features are described herein with reference to the accompanying drawings. It should be noted that the drawings are only intended to facilitate the description of the features. The various features described are not intended as an exhaustive description of the subject matter disclosed herein or as a limitation on the scope of the subject matter disclosed herein. In addition, the examples shown need not have all aspects or advantages shown. Aspects or advantages described in connection with a particular example need not be limited to that example and may be practiced in any other example even if not so shown or if not so expressly described.

[0055] In addition, any element that does not expressly state "means" for performing a specified function or "step" for performing a particular function in a claim should not be construed as the specified "means" or "step". In particular, the use of "step of..." or "act of..." in the claims herein is not intended to invoke the relevant provisions.

[0056] It should be noted that if used, the labels "left, right, front, back, top, bottom, forward, backward, clockwise, and counterclockwise" are only for convenience purposes and are not intended to imply any particular fixed direction. Instead, the labels are used to reflect the relative positions and / or orientations between the various parts of an object.

[0057] Any data processing may include data buffering, aligning incoming data from multiple communication channels, forward error correction ("FEC"), and / or others. For example, data may first be received by an analog front end (AFE), which prepares the incoming data for digital processing. The digital part of the transceiver (e.g., DSP) may provide skew management, equalization, reflection cancellation, and / or other functions. It should be understood that the processing described herein may provide many benefits, many of which include saving both power and cost.

[0058] In addition, the terms "system", "component", "module", "interface", "model", etc. generally refer to a computer-related entity or a combination of hardware, hardware and software, software, or software in execution. For example, a component may be, but is not limited to, a process running on a processor, a processor, an object, an executable file, a thread being executed, a program, and / or a computer. By way of illustration, an application running on a controller and the controller can both be components. One or more components may reside within a process and / or a thread being executed, and a component may be located on one computer and / or distributed between two or more computers.

[0059] Unless otherwise expressly stated, each numerical value and range can be interpreted as approximate, as the word "about" or "approximate" before a value or range of values. A signal and the corresponding node or port may be referred to by the same name and are interchangeable herein for purposes.

[0060] Although embodiments have been described with respect to circuit functionality, embodiments of the subject matter disclosed herein are not so limited. Possible implementations may be embodied in a single integrated circuit, a multi-chip module, a single card, a system-on-chip, or a multi-card circuit pack. As will be apparent to those skilled in the art, various embodiments may also be implemented as part of a larger system. Such embodiments may be employed in conjunction with, for example, a digital signal processor, a microcontroller, a field programmable gate array, an application specific integrated circuit, or a general purpose computer.

[0061] As will be apparent to those skilled in the art, the various functions of circuit elements may also be implemented as processing blocks in a software program. Such software may be employed in, for example, a digital signal processor, a microcontroller, or a general purpose computer. Such software may be embodied in the form of program code embodied in a tangible medium such as, for example, a magnetic recording medium, an optical recording medium, a solid state memory, a floppy disk, a CD-ROM, a hard disk drive, or any other non-transitory machine-readable storage medium, which, when loaded into and executed by a machine such as a computer, causes the machine to become an apparatus for practicing the subject matter disclosed herein. When implemented on a general purpose processor, the program code segments combine with the processor to provide a unique device that operates similarly to a specific logic circuit. The described embodiments may also be embodied in the form of signal values, such as bitstreams or other sequences transmitted electro-optically through a medium as described herein, or magnetic field changes stored in a magnetic recording medium, etc., generated using the methods and / or apparatuses described herein.

[0062] In some examples, persistent memory (PMEM) (also referred to as a persistent storage device) may include a solid state memory device that can retain data when power is removed. PMEM may be referred to as non-volatile memory (NVM) or storage class memory (SCM). PMEM may be a solid state high performance byte-addressable memory device residing on a memory bus. PMEM may be used by applications that are sensitive to downtime and have high performance constraints, such as, for example, data centers, etc.

[0063] In some aspects, Compute Express Link (CXL) can include a high-speed, high-capacity connection between a CPU and a device. CXL can be used in various types of servers, high-performance data center computers, etc. CXL can be used in conjunction with Peripheral Component Interconnect (PCI) Express (PCIe). CXL can be configured to maintain a unified memory space. CXL can increase efficiency by allowing composability, scalability, and flexibility of heterogeneous and distributed computing architectures. Since in some cases, CXL can support up to, for example, 32 lanes, while PCIe can be limited to, for example, a maximum of 16 lanes, CXL can provide more bandwidth than PCIe. CXL enables memory sharing between devices, allowing devices to work together more effectively. CXL can be configured to support various protocols (such as CXL.io, CXL.mem, CXL.cache, etc.).

[0064] CXL Intellectual Property (IP) can include logic configured to build CXL devices, hosts, or switches. In some cases, CXL IP can also be configured to support runtime-selectable dual-mode applications between device and host modes. CXL IP can provide secure, low-latency, and high-bandwidth interconnects for artificial intelligence (AI), machine learning, cloud computing applications, etc. In some cases, CXL IP can include a controller, a physical layer (PHY), an integrated development environment (IDE) security module, verification IP. In some aspects, IP-level verification focuses on verifying the functionality of individual intellectual property (IP) blocks or modules. In some cases, an IP block can include components (such as a processor, a memory controller, a dedicated hardware accelerator). System-on-chip (SoC)-level verification can be configured to include verifying the entire SoC, which can include integrating the behavior of multiple IP blocks, interconnects, and / or the overall system.

[0065] In some aspects, a memory eviction policy may be based on an algorithm that determines how to manage data in memory. Memory eviction (e.g., memory management) may include a feature in which file data blocks in memory are removed when a soft quota is exceeded to create space for new files. For example, a web browser may store images, code, fonts, icons, and other items to help a page load quickly. In some cases, this cache space may fill up relatively quickly. An eviction algorithm may be configured to decide which items to keep in the cache and which items to evict. In some methods, a memory eviction policy may use knowledge of the activity in memory and any configuration provided at startup to determine which data blocks (if any) should be evicted. In some aspects, a least recently used (LRU) policy in which the least recently used items are removed may be used. Additionally or alternatively, a first in first out (FIFO) algorithm may be used when the use of an element makes it less likely to be used in the future. Additionally or alternatively, a time to leave (TTL) algorithm in which each data entry (e.g., data block, cache entry, etc.) is marked with an expiration date may be used. In some cases, once the time limit has passed, the data may be evicted (e.g., regardless of how frequently and / or recently the data has been accessed). Additionally or alternatively, a least frequently used (LFU) policy in which the data entries that have been used the least number of times may be removed may be used. In some cases, a memory eviction policy may be configured to evict data when a data metric and / or access metric corresponding to the data meets an eviction threshold or other eviction criteria for selectively removing data from memory (e.g., volatile memory, cache, etc.).

[0066] In some aspects, eviction may include the process of removing old, unused, or large data from the cache. In some cases, this may allow the cache to stay within a memory budget. In some cases, an eviction server may use the LRU algorithm to find and evict pages in memory that have not been accessed recently. Not all data can be kept in memory at any given time. In some aspects, eviction may be responsible for making space for new data by freeing infrequently accessed data in memory. In some cases, an eviction server may (e.g., based on the LRU algorithm) periodically find pages in memory that have not been accessed within a certain time. In some cases, one or more background eviction threads may be configured to continuously process these pages, coordinating these pages to a storage device and / or removing these pages from memory.

[0067] In some aspects, a dynamic random access memory (DRAM) can include a type of semiconductor memory that stores data (e.g., stores data in the main memory of a computer system). In some cases, DRAM can be a volatile type of RAM memory (e.g., DRAM loses data when power is removed). In some examples, a static RAM (SRAM) can include a type of memory that uses flip - flops to store each bit. SRAM can be volatile memory (e.g., SRAM loses data when power is removed). In some examples, SRAM can be used as a cache (e.g., the L1 cache, L2 cache of a processor), while DRAM can be used as main memory or system memory.

[0068] In some aspects, flash memory can include non - volatile memory that can store data and transfer data between a host and other digital devices. In some cases, flash memory can be electrically erased and reprogrammed. A solid - state drive (SSD) can include a type of non - volatile storage medium that can be configured to store data on solid - state flash memory. In some cases, an SSD can be used as an auxiliary storage device in the storage hierarchy of a computer. Non - volatile memory express (NVMe) can include a transfer protocol that accelerates the transfer of data in a solid - state storage device (SSD). NVMe can use a Peripheral Component Interconnect Express (PCIe) bus to connect an SSD storage device to a CPU or server. NAND flash memory can include a non - volatile storage technology that stores data without the need for power. NAND flash memory can be referred to as memory chips. Flash cards and SSDs can be configured to use multiple NAND flash chips to store data. In data management, "hot" data can refer to data that is frequently accessed or in high demand. Hot data can be in demand and in transit regularly and, in some cases, is not stored for a long time. Thus, data hotness can indicate the relative degree of how frequently data is accessed or requested.

[0069] In some examples, a Global Persistent Flush (GPF) can include a hardware mechanism that disperses all non-persistent data to a persistent destination on the same CXL domain (e.g., on the same device or another device in the same coherency domain). The CXL link (and the protocol agents on the devices coupled through the link) can be configured to support asynchronous DRAM refreshes, the GPF protocol, and / or streaming. In some cases, the GPF can be implemented as a hardware-based mechanism associated with persistent memory that is used to flush caches and memory buffers to the persistent domain. The GPF can be triggered by specific events where software cannot flush data (such as, for example, in response to an indication of an impending power loss or an abnormal reset, among other examples). Additionally or alternatively, the CXL agent can be configured to detect and identify errors using messaging associated with the GPF stream, which, in some cases, can occur during an attempt to flush to persistent memory. In some cases, assuming that persistent data (e.g., persistent data relied upon by the applications of the system) can be at risk and any possible loss of persistent data can be logged to ensure correct and trustworthy operation, among other considerations, startup errors detected through the GPF stream can be used to improve system reliability. For a storage expansion unit, for example, the GPF can be used to ensure that in-flight data (e.g., all in-flight data), whether being written or having been reported as written (e.g., while still in the cache or memory), is either completed in the persistent destination or a path to the data is found to route along the path to other persistent locations.

[0070] In mathematical notation, ++ can be used to indicate that the value of an operand is incremented by 1 (e.g., a++ is equivalent to a = a + 1). Similarly, -- can be used to indicate that the value of an operand is decremented by 1 (e.g., a-- is equivalent to a = a - 1). Additionally, += and -= are operators that can be used to add a value to or subtract a value from a variable, respectively, and the result is re-assigned to the variable. For example, a += b can indicate that the value of the right operand is added to the original value of the left operand, resulting in a new value for the left operand (e.g., a += b is equivalent to a = a + b). Similarly, a -= b can indicate that the value of the right operand is subtracted from the original value of the left operand, resulting in a new value for the left operand (e.g., a -= b is equivalent to a = a - b).

[0071] In some aspects, Weighted Round Robin (WRR) may include a process scheduling algorithm that can be configured to use a load balancing system and method. In some cases, WRR can be a more advanced version of the basic round robin algorithm, and WRR distributes tasks evenly across all nodes (e.g., devices, device components, SoCs, systems, hosts, etc.). WRR can be a generalization of round robin scheduling, and in some cases, WRR can serve queue groups or task groups. In some cases, WRR can maintain a weighted list of nodes and forward new requests / processes in proportion to the weight of each node. In some aspects, weights can be assigned to each node based on preset criteria and / or dynamic criteria, and the dynamic criteria modify the criteria according to the environment and without human input. The criteria can include the process handling capabilities of the nodes. In certain cases, the higher the weight, the greater the proportion of requests / processes processed by the node.

[0072] The systems and methods described herein provide a configurable eviction / arbiter policy based on background eviction-based low-latency global persistence flushing. The described systems and methods use metadata processing with a metadata storage device to record DRAM data dirty states and age states, etc. The eviction requester decides the data to be dumped to persistent memory (e.g., NAND / SSD) based on the metadata state. The metadata state includes the percentage of dirty data (or bad data) based on a global register for the dirty state of each DRAM page, data lifetime (e.g., data validity period), data age, etc. The arbiter controls incoming requests to the data controller based on the priority of host load / store (LD / ST) requests relative to eviction requests, incoming data patterns, data age, data hotness, etc. In some cases, the data controller (e.g., Figure 2 the data controller) can process requests from the arbiter, where the request is based on a configurable eviction / arbiter policy.

[0073] In some method cases, CXL PMEM can expose the device DRAM as a host-managed memory space with persistence to the host. Thus, during some operations, transferring host load / store (LD / ST) data to the DRAM of CXL PMEM is completed with relatively low latency. During power-off and GPF phases, all DRAM data can be dumped to NAND / SSD for persistence, increasing the latency. During the power-on phase, the data dumped to NAND / SSD can be loaded from NAND / SSD to DRAM, further increasing the latency.

[0074] In the case of some methods, the CXL GPF stream may include GPF Phase 1 and GPF Phase 2 (e.g., GPF Persistent Flush 1 (PF1), GPF PF2). For such a system, all DRAM data may be dumped to persistent memory (e.g., NAND / SSD) based on a given persistent flush trigger. However, transferring all data in DRAM to persistent memory may take a relatively long time (e.g., 3 to 4 seconds for 16GB of data in the case of an NVMe Gen4 SSD). In some cases, the host firmware may not be configured to receive the GPF PF2 acknowledgment (ACK) in a timely manner. A given device (e.g., a CXL PMEM device) may require a relatively large number of energy units to ensure that DRAM data is successfully dumped to NAND / SSD. This results in such a system having a relatively high cost and may result in limited CXL PMEM capacity (e.g., due to form factor limitations).

[0075] In some aspects, the systems and methods described herein address the relatively high cost and relatively high latency of other systems. For example, the systems and methods described herein include logic for providing low-latency global persistent flushing based on background eviction. The logic may include any combination of hardware (e.g., at least one memory, at least one processing unit), logic circuits, firmware, and / or software to provide low-latency global persistent flushing based on background eviction. The systems and methods described herein may provide a metadata processor and a storage device for metadata that describes or indicates information about data stored in DRAM. In some examples, the metadata processor may record data stored in DRAM and store a description of the data as metadata in a metadata storage device. The metadata may include the dirty state of the DRAM data, the age of the DRAM data, etc.

[0076] In some examples, the system and method may provide an eviction requester configured to determine data to be dumped to persistent memory (e.g., NAND / SSD) based on the metadata state provided by the metadata processor. The metadata state may include the percentage of dirty data, data lifetime, etc. The systems and methods described herein may provide an arbiter configured to control incoming requests to a data controller based on the priority of host LD / ST requests relative to eviction requests, based on weighted round-robin, based on incoming data patterns, data age, and / or based on data hotness, etc.

[0077] The systems and methods described herein may provide a data controller that performs data processing based on requests from an arbiter. The systems and methods described herein may provide a configurable eviction / arbiter policy based on a low-latency global persistence flush based on background eviction. Accordingly, the systems and methods described herein may include logic for providing a low-latency global persistence flush based on background eviction.

[0078] Figure 1 FIG. 100 illustrates an example system 100 in accordance with one or more embodiments as described herein. In Figure 1 FIG. 100, a machine 105 is illustrated, which may be referred to as a host, system, or server. Although Figure 1 the machine 105 is depicted as a tower computer, the disclosed embodiments may extend to any form factor or type of machine. For example, the machine 105 may be a rack server, blade server, desktop computer, tower computer, mini-tower computer, desktop server, laptop computer, notebook computer, tablet computer, etc.

[0079] The machine 105 may include a processor 110, a memory 115, and a storage device 120. The processor 110 may be any kind of processor. Note that, for ease of illustration, the processor 110, along with other components discussed below, is shown outside of the machine: the disclosed embodiments may include these components within the machine. Although Figure 1 a single processor 110 is shown, the machine 105 may include any number of processors, each of any number of processors may be a single-core or multi-core processor, and each of the single-core or multi-core processors may implement a reduced instruction set computer (RISC) architecture or a complex instruction set computer (CISC) architecture (among other possibilities), and may be mixed in any desired combination.

[0080] Processor 110 may be coupled to memory 115. Memory 115 can be any kind of memory (such as, flash memory, dynamic random access memory (DRAM), static random access memory (SRAM), persistent random access memory, ferroelectric random access memory (FRAM), or non-volatile random access memory (NVRAM) (such as, magnetoresistive random access memory (MRAM), phase change memory (PCM), or resistive random access memory (ReRAM))). Memory 115 may include volatile and / or non-volatile memory. Memory 115 may use any desired form factor: for example, single in-line memory module (SIMM), dual in-line memory module (DIMM), non-volatile DIMM (NVDIMM), etc. Memory 115 may be any desired combination of different memory types and may be managed by memory controller 125. Memory 115 may be used to store data that may be referred to as "short-term": that is, data that is not expected to be stored for an extended period of time. Examples of short-term data may include temporary files, data used locally by an application (which may have been copied from other storage locations), etc.

[0081] Processor 110 and memory 115 may support an operating system under which various applications may be running. These applications may issue requests (which may be referred to as commands) to read data from or write data to memory 115 or storage device 120. When storage device 120 is used to support an application that reads or writes data via a certain file system, device driver 130 may be used to access storage device 120. Although Figure 1 One storage device 120 is shown, but any number (one or more) of storage devices may be present in machine 105. Storage device 120 may support any desired one or more protocols, including for example the Non-Volatile Memory Express (NVMe) protocol, Serial Attached SCSI (SAS) protocol, or Serial ATA (SATA) protocol. Storage device 120 may include any desired interface, including for example a Peripheral Component Interconnect Express (PCIe) interface or a Compute Express Link (CXL) interface. Storage device 120 may adopt any desired form factor, including for example the U.2 form factor, U.3 form factor, M.2 form factor, Enterprise and Data Center Standard Form Factor (EDSFF) (including all kinds of EDSFF (such as, E1 short, E1 long, and E3 kinds)), or an Add-in Card (AIC).

[0082] Although Figure 1The term "storage device" is used, but the disclosed embodiments may include any storage device format that can benefit from the use of computing storage units. Examples of any storage device format may include hard disk drives, solid state drives (SSDs), or persistent memory devices (such as PCM, ReRAM, or MRAM). Any reference herein to "storage device" or "SSD" should be understood to include such other disclosed embodiments and other types of storage devices. In some cases, the term "storage unit" may include storage device 120 and memory 115.

[0083] Machine 105 may include power supply 135. Power supply 135 may supply power to machine 105 and the components of machine 105. Machine 105 may include transmitter 145 and receiver 150. Transmitter 145 or receiver 150 may be used, respectively, to send or receive data (e.g., to / from volatile memory and / or to / from persistent memory (NAND / SSD)). In some cases, transmitter 145 and / or receiver 150 may be used to communicate with memory 115 and / or storage device 120. Transmitter 145 may include write circuit 160, which may be used to write data (e.g., metadata) into a storage device (such as a register) in memory 115 and / or storage device 120. In a similar manner, receiver 150 may include read circuit 165, which may be used to read data (e.g., metadata) from a storage device (such as a register) in memory 115 and / or storage device 120.

[0084] In the example shown, machine 105 may include timer 155. Timer 155 may be used to maintain (or control) one or more counters (such as, for example, a data age counter, a dirty data counter, a hot data counter, a host request counter, etc.).

[0085] In one or more examples, machine 105 may be implemented with any type of device. Machine 105 may be configured as one or more (e.g., as its host) of servers (such as computing servers, storage servers, storage nodes, network servers, supercomputers, data center systems, etc. or any combination thereof). Additionally or alternatively, machine 105 may be configured as one or more (e.g., as its host) of computers (such as workstations, personal computers, tablet computers, smart phones, etc. or any combination thereof). Machine 105 may be implemented with any type of device that may be configured as a device including, for example, accelerator devices, storage devices, network devices, memory expansion and / or buffer devices, central processing units (CPUs), graphics processing units (GPUs), neural processing units (NPUs), tensor processing units (TPUs), etc. or any combination thereof.

[0086] Any communication between devices including machine 105 (e.g., a host, a compute storage device, and / or any intermediate device) can occur through an interface, which can be implemented with any type of wired and / or wireless communication medium, interface, protocol, etc. Any type of wired and / or wireless communication medium, interface, protocol, etc. includes PCIe, NVMe, Ethernet, NVMe-oF, Compute Express Link (CXL), and / or coherence protocols (such as CXL.mem, CXL.cache, CXL.IO, etc.), Gen-Z, Open Coherent Accelerator Processor Interface (OpenCAPI), Cache Coherent Interconnect for Accelerators (CCIX), Advanced eXtensible Interface (AXI), etc., or any combination thereof, Transmission Control Protocol / Internet Protocol (TCP / IP), Fibre Channel, InfiniBand, Serial ATA (SATA), Small Computer System Interface (SCSI), Serial Attached SCSI (SAS), iWARP, any generation of wireless network including 2G, 3G, 4G, 5G, etc., any generation of Wi-Fi, Bluetooth, Near Field Communication (NFC), etc., or any combination thereof. In some embodiments, the communication interface can include a communication fabric, which includes one or more links, buses, switches, hubs, nodes, routers, translators, repeaters, etc. In some embodiments, system 100 can include one or more additional devices having one or more additional communication interfaces.

[0087] Any of the functions described herein, including any of the host function, device function, PMEM controller 140 function, etc., can be implemented with hardware, software, firmware, or any combination thereof. Hardware, software, firmware, or any combination thereof includes, for example, hardware and / or software combinational logic, sequential logic, timers, counters, registers, state machines, volatile memory (such as dynamic random access memory (DRAM) and / or static random access memory (SRAM)), non-volatile memory (including flash memory, persistent memory (such as cross-grid non-volatile memory), memory with bulk resistance change, phase change memory (PCM), etc., and / or any combination thereof), complex programmable logic devices (CPLDs) that execute instructions stored in any type of memory, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), CPUs including complex instruction set computer (CISC) processors (such as x86 processors) and / or reduced instruction set computer (RISC) processors (such as RISC-V and / or ARM processors), graphics processing units (GPUs), neural processing units (NPUs), tensor processing units (TPUs), etc. In some embodiments, one or more components of PMEM controller 140 can be implemented as a system on a chip (SOC).

[0088] In some examples, the PMEM controller 140 may include any one or combination of logic (e.g., logic circuits), hardware (e.g., processors, memories, storage devices), software, firmware, etc. In some cases, the PMEM controller 140 may execute one or more functions in conjunction with the processor 110. In some cases, at least part of the PMEM controller 140 may be implemented in or by the processor 110 and / or the memory 115. One or more logic circuits of the PMEM controller 140 may include any one or combination of a multiplexer, registers, logic gates, an arithmetic logic unit (ALU), a cache, computer memory, a microprocessor, a processor (CPU, GPU, NPU, and / or TPU), an FPGA, an ASIC, etc., that enable the PMEM controller 140 to provide low-latency global persistent flushing based on background eviction.

[0089] In one or more examples, the PMEM controller 140 may dump volatile data to a persistent storage device during device idle time. Dumping data during device idle time reduces the GPF dump time and significantly saves energy. Additionally, based on the volatile data being dumped to the persistent storage device during device idle time, a response to the host during the GPF phase is made in a timely manner, thus reducing system overhead. Based on the reduced dump energy being consumed, the CXL PMEM storage capacity (e.g., for NVMe server storage subsystem form factors, NVMe SSD form factors (such as E3.5, etc.)) is increased.

[0090] Figure 2 showing details of the Figure 1 machine 105 according to the examples described herein. In Figure 2 general, the machine 105 includes one or more processors 110, and one or more processors 110 may include a memory controller 125 and a clock 205, and the clock 205 may be used to coordinate the operation of the components of the machine. The processor 110 may be coupled to a memory 115, and as an example, the memory 115 may include random access memory (RAM), read-only memory (ROM), or other state-saving media. The processor 110 may be coupled to a storage device 120 and to a network connector 210, and the network connector 210 may be, for example, an Ethernet connector or a wireless connector. The processor 110 may be connected to a bus 215, and a user interface 220 and an input / output (I / O) interface port may be attached to the bus 215, and the user interface 220 and the input / output (I / O) interface port may be managed using an I / O engine 225 and other components. As shown, the processor 110 may be coupled to a PMEM controller 230, and the PMEM controller 230 may be Figure 1An example of the PMEM controller 140. Additionally or alternatively, the processor 110 may be connected to the bus 215, and the PMEM controller 230 may be attached to the bus 215. In some cases, the bus 215 may include a CXL bus.

[0091] Figure 3 Illustrates an example system 300 according to one or more embodiments described herein. System 300 illustrates an example system for low-latency GPF based on background eviction. In the example shown, system 300 includes a host 305 that is communicatively connected to a CXL Persistent Memory (PMEM) 315 via a bus 310 (e.g., a CXL bus). As shown, the host may include firmware 320 (e.g., platform firmware, host firmware). As shown, the CXL PMEM 315 may include a PMEM controller 325, DRAM 370, and persistent memory 375 (e.g., NAND flash, SSD, etc.). In some examples, the PMEM controller 325 may be Figure 1 an example of the PMEM controller 140 and / or Figure 2 an example of the PMEM controller 230. As shown, the PMEM controller 325 may include a CXL IP 330 (e.g., port logic), an arbiter 335, an eviction requester 340 (e.g., a memory manager), and a GPF controller 345 connected to the CXL IP 330 via a CXL input / output connection (e.g., CXL.io 350). In the example shown, the PMEM controller 325 may include a data controller 355, a metadata processor 360 (e.g., a metadata controller), and metadata 365 (e.g., a storage device storing metadata, a register storing metadata, a global register, etc.). In some cases, at least part of the metadata 365 may be stored in SRAM. In some examples, the data path from the host to the DRAM 370 and / or to the persistent memory 375 may travel from the host 305 to the CXL IP3 30, from the CXL IP3 30 to the arbiter 335, from the arbiter 335 to the data controller 355, and from the data controller 355 to the DRAM 370 and / or to the persistent memory 375.

[0092] In one or more examples, the metadata processor 360 works with metadata 365 (e.g., metadata related to the data of DRAM 370 and / or the data of persistent memory 375). For example, the metadata processor 360 can work with the storage device of the PMEM controller 325 that stores the metadata 365 and / or the memory device. In some embodiments, the metadata processor 360 records data associated with the CXL PMEM 315 (e.g., the data of DRAM 370, the data of persistent memory 375, metadata 365, etc.). In some cases, the metadata processor 360 monitors the dirty state of data (e.g., the data of DRAM 370). In some cases, the metadata processor 360 monitors the age of data (e.g., DRAM data). In some examples, the metadata processor 360 includes any combination of hardware (e.g., at least one memory, at least one processor), logic circuitry, firmware, and / or software configured to provide low-latency GPF based on background eviction.

[0093] In one or more examples, the eviction requester 340 can be configured to determine when a data dump to the persistent memory 375 occurs based on the metadata state determined from the metadata 365 (e.g., based on one or more indications of information included in the metadata 365). Some examples of the metadata state can include the percentage of dirty data based on a global register configured for the dirty state of one or more memory pages (e.g., 16KB pages) of the DRAM 370. In some cases, the metadata state can include the data validity period (e.g., the lifespan or validity period of DRAM data, data age, etc.). In some examples, the eviction requester 340 includes any combination of hardware (e.g., at least one memory, at least one processor), logic circuitry, firmware, and / or software configured to provide low-latency GPF based on background eviction.

[0094] In one or more examples, the arbiter 335 controls the incoming requests to the data controller 355 based on at least one criterion. In some examples, the at least one criterion can include the priority of the host load / store (LD / ST) request relative to the priority of the eviction request (e.g., associated with the data in the DRAM 370). For example, when the arbiter 335 determines that the priority of the eviction request exceeds the priority of the host LD / ST request, the arbiter 335 can allow the eviction request to proceed. In some cases, when the arbiter 335 determines that the priority of the eviction request does not exceed the priority of the host LD / ST request, the arbiter 335 can block or delay the eviction request.

[0095] In some examples, at least one criterion may include an incoming data pattern (e.g., access frequency based on data type, pattern of hot data, pattern of cold data, pattern of hot and cold data, etc.), data age, and / or data hotness (e.g., associated with data in DRAM 370). In some examples, arbiter 335 includes any combination of hardware (e.g., at least one memory, at least one processor), logic circuitry, firmware, and / or software configured to provide low-latency GPF based on background eviction. In one or more examples, arbiter 335 may grant more eviction requests to data controller 355 based on the arbiter 335 detecting device idle time. In some cases, the background eviction systems and methods described herein enable PMEM controller 325 to back up at least a portion (e.g., all) of the content of DRAM 370 during idle time such that when an event occurs (e.g., power loss), at least a portion of DRAM 370 has been backed up, thus reducing system latency.

[0096] In some examples, arbiter 335 may adjust an eviction threshold (e.g., an eviction threshold stored in a register of metadata 365) based on a device profile (e.g., memory capacity, storage capacity, data transfer rate (e.g., maximum data transfer rate), processing speed, processing capacity, etc.). In some examples, arbiter 335 may adjust the eviction threshold based on the idle state of host 305 and / or the idle state of PMEM controller 325. For example, when arbiter 335 determines that host 305 is relatively busy, arbiter 335 may adjust the eviction threshold accordingly (e.g., adjust the eviction threshold to reduce the eviction rate when host 305 is busy). When arbiter 335 determines that host 305 is idle, arbiter 335 may adjust the eviction threshold accordingly (e.g., adjust the eviction threshold to increase the eviction rate when host 305 is idle).

[0097] In one or more examples, data controller 355 performs data processing in accordance with requests (e.g., eviction requests) from arbiter 335. For example, data controller 355 may dump volatile data of DRAM 370 to persistent memory 375 based on a request from arbiter 335 (e.g., based on device idle time). In some examples, data controller 355 includes any combination of hardware (e.g., at least one memory, at least one processor), logic circuitry, firmware, and / or software configured to provide low-latency GPF based on background eviction. Thus, as described herein, the components of the depicted system 300 provide a configurable eviction / arbiter policy implemented through low-latency GPF based on background eviction.

[0098] In one or more examples, the metadata processor 360 may be configured to generate metadata 365 based on monitoring data in volatile memory (e.g., DRAM 370) by the metadata processor 360. In some cases, the eviction requester 340 may be configured to trigger an eviction request for evicting data in DRAM 370 based on the metadata 365. In some examples, the data controller 355 may be configured to analyze the eviction request relative to at least one request criterion by the arbiter 335 and forward the eviction request to the data controller 355 based on the result of the analysis to process the eviction request. In some examples, processing the eviction request includes the data controller 355 also being configured to move data during device idle time.

[0099] In one or more examples, the request criterion may be based on the priority of the eviction request relative to the priority of requests to the host 305. Additionally or alternatively, the request criterion may be based on the pattern of data in DRAM 370. Additionally or alternatively, the request criterion may be based on at least one of the following: the age of the data in DRAM 370, the heat of the data in DRAM 370, and / or a weighted round-robin selection process for determining which request to process (e.g., which request to process next).

[0100] Additionally or alternatively, the request criterion may be based on the number of requests (e.g., eviction requests) pending at the eviction requester 340 relative to the number of requests (e.g., eviction requests) pending at the host 305. Additionally or alternatively, the request criterion may be based on the frequency of requests at the eviction requester 340 relative to the frequency of requests at the host. Additionally or alternatively, the request criterion may be based on the eviction requester 340 determining that the host 305 is in an idle state.

[0101] In one or more examples, the metadata 365 describes the data in DRAM 370. In some examples, the metadata 365 may include at least one of the following: the dirty state of the data in volatile memory and / or the age of the data in volatile memory.

[0102] Additionally or alternatively, the metadata 365 may include at least one of a dirty data count (e.g., total dirty data count), a hot data count (e.g., total hot data count), a host request count, an eviction threshold, and / or a data heat threshold (e.g., heat threshold). In some examples, the metadata 365 may be stored in one or more registers. For example, a first register may include a dirty data counter indicating the count of dirty data (e.g., total dirty data count), while a second register may include an eviction threshold.

[0103] Figure 4Illustrates an example system 400 according to one or more embodiments described herein. System 400 illustrates an example metadata structure for low-latency GPF based on background eviction. In the illustrated example, system 400 includes SRAM 405, DRAM 410 (e.g., volatile memory), and registers 415 (e.g., storage devices for metadata such as Figure 2 metadata 365). In some examples, system 400 illustrates Figure 2 an example metadata structure and / or metadata storage device for metadata processor 360 and / or metadata 365. DRAM 410 may be an example of Figure 3 DRAM 370. SRAM 405 and / or registers 415 may store Figure 3 at least a portion of metadata 365 (e.g., metadata 365).

[0104] In the illustrated example, SRAM 405 includes a dirty bitmap 420, in which a binary 1 may indicate dirty and a binary 0 may indicate clean (e.g., or vice versa). In some embodiments, SRAM 405 may include a hot bitmap 425, in which a binary 1 may indicate hot and a binary 0 may indicate cold (e.g., or vice versa). In some examples, SRAM 405 may include an age counter 430. In some cases, metadata processor 360 may adjust dirty bitmap 420, hot bitmap 425, and / or age counter 430 based on data processing (e.g., read operations, write operations, eviction operations, etc.).

[0105] In the illustrated example, DRAM 410 may include one or more pages (e.g., 16KB DRAM memory pages). In some cases, the values stored in registers 415 (e.g., counter values, thresholds, etc.) may be at least partially based on the values stored in SRAM 405 (e.g., dirty bitmap 420, hot bitmap 425, age counter 430). In some examples, the values stored in SRAM 405 may be based on the data stored in DRAM 410.

[0106] In some examples, the counters of registers 415 (e.g., age counter 430, total dirty data counter 435, total hot data counter 440, and / or host request counter 450) may be global counters (e.g., global registers). In some cases, the counters of registers 415 may be updated on the fly (e.g., via metadata processor 360) for each DRAM data request.

[0107] In some examples, the counter of register 415 (e.g., metadata such as metadata 365) may be updated based on the relevant data page of DRAM 410. In some cases, the data page size may be configurable (e.g., based on the NAND page size and / or the DRAM page size). In some cases, register 415 may include at least one register for maintaining the host request counter 450, such that the metadata processor 360 can monitor the device busy state (e.g., the busy state of host 305 indicating the level of data traffic initiated by host 305).

[0108] In some examples, the structure or size of SRAM 405 (e.g., for metadata, for all metadata, metadata 365, etc.) may be configured for relatively fast access (e.g., relatively fast access by the metadata processor 360). In some cases, the dirty bitmap 420, the hot bitmap 425, and / or the age counter 430 may be configured as rows of a certain number of bits (e.g., each configured as a 7-bit row in the depicted example or co-configured as a certain number of bits based on the system configuration).

[0109] In one or more examples, for the data pages of DRAM 410 (e.g., for each DRAM data page), the metadata structure of system 400 may include the dirty bit flag of the dirty bitmap 420, the hot flag bit of the hot bitmap 425, and / or the value of the age counter 430 (e.g., the 6-bit value of the age counter 430). In some cases, the metadata structure of system 400 (e.g., 1 bit of the dirty bitmap 420, 1 bit of the hot bitmap 425, 6 bits of the age counter 430) may be configured by the host (e.g., Figure 3 host 305). In some cases, the metadata structure may be configured by the host based on CXL.io (e.g., based on the CXL.io protocol via the CXL bus 310). In some embodiments, the values of the dirty bitmap 420, the hot bitmap 425, and / or the age counter 430 may correspond to at least one page of DRAM 410. For example, the value of the dirty bitmap 420 (e.g., the top value "1" of the dirty bitmap 420 as shown Figure 4 in) may correspond to the page of DRAM 410 (e.g., the top page of DRAM 410 as shown Figure 4 in). Additionally or optionally, the value of the hot bitmap 425 (e.g., the top value "0" of the hot bitmap 425 as shown Figure 4 in) may correspond to the page of DRAM 410 (e.g., the top page of DRAM 410 as shown Figure 4 in). Additionally or optionally, the value of the age counter 430 (e.g., as shown Figure 4The top value “00010” of the age counter 430 shown in can correspond to a page of the DRAM 410 (e.g., the top page of the DRAM 410 shown in Figure 4 ).

[0110] As shown, the register 415 can include at least one of a total dirty data counter 435, a total hot data counter 440, an eviction threshold 445, a host request counter 450, and / or a hot threshold 455. For example, the register 415 can include a first register containing the total dirty data count, a second register containing the total hot data count, a third register containing a selected eviction threshold, a fourth register containing the host request count, and / or a fifth register containing a selected hot threshold.

[0111] In one or more examples, the eviction threshold 445 indicates a threshold based on the memory capacity of the DRAM 410. In some cases, the eviction threshold 445 can be a portion and / or percentage (e.g., any percentage from 0% to 100%) of the memory capacity of the DRAM 410. For example, in the case where the DRAM 410 has a 16 GB memory capacity, the eviction threshold 445 can be set at 12 GB or 75% of the memory capacity, at 10 GB or 62.5% of the memory capacity, at 8 GB or 50% of the memory capacity, etc. In some cases, the arbiter 335 can be configured to select the eviction threshold 445. Additionally or alternatively, a user can select the eviction threshold 445.

[0112] In some examples, the hot threshold 455 indicates a threshold at which data (e.g., data in a volatile memory such as the DRAM 410) can be considered (e.g., determined by Figure 3 the metadata processor 360 of) hot by the system 400. In some cases, the hot threshold 455 can be based on the frequency at which data (e.g., data of the DRAM 410) is accessed, requested, in demand, and / or in transit. When the frequency of accessing data (e.g., at least a portion of the data of the DRAM 410) meets the hot threshold (e.g., a predetermined or dynamically selected frequency value), then the system 400 (e.g., the metadata processor 360) can determine that the data is hot. For example, when the frequency of accessing data meets (e.g., is greater than or greater than or equal to) the hot threshold 455, the data can be determined to be hot. In some cases, the values stored in the register 415 (e.g., the depicted counters, thresholds, etc.) can be at least partially based on the values stored in the SRAM 405 (e.g., the dirty bitmap 420, the hot bitmap 425, the age counter 430). In some examples, the hotness of data (e.g., a file, a document, etc.) is indicated by the hot bits of the hot bitmap 425. In some cases, the value of a hot bit is based on the value of the age counter 430 and / or the value of the hot threshold.

[0113] In some examples, the metadata processor 360 may maintain a total dirty data counter 435 such that the eviction requester 340 can manage eviction based on the total dirty data counter 435. For example, the metadata processor 360 may provide data from the total dirty data counter 435 such that the eviction requester 340 can manage eviction based on the total dirty data counter 435. In some examples, the metadata processor 360 may maintain a total hot data counter 440 such that the eviction requester 340 can manage eviction based on the total hot data counter 440 (e.g., such that the eviction requester 340 can avoid evicting hot data that would result in relatively large NAND write amplification).

[0114] Figure 5 A flowchart depicting an example method 500 associated with the disclosed system in accordance with example embodiments described herein. Method 500 illustrates an example flow of read requests based on background eviction for low-latency GPF. In some configurations, method 500 may be implemented by Figure 1 the PMEM controller 140, Figure 2 the PMEM controller 230, and / or Figure 3 the PMEM controller 325. In some examples, one or more aspects of method 700 may be performed by and / or in conjunction with one or more components of the PMEM controller 325 (e.g., the arbiter 335, the eviction requester 340, the GPF controller 345, the data controller 355, the metadata processor 360, the DRAM 370, the persistent memory 375, etc.). In some configurations, method 500 may be implemented in conjunction with the machine 105, components of the machine 105, or any combination thereof. The depicted method 500 is merely one implementation, and one or more operations of method 500 may be rearranged, reordered, omitted, and / or otherwise modified such that other implementations are possible and contemplated.

[0115] At operation 505, method 500 may include receiving an incoming read request. For example, the PMEM controller 325 may receive an incoming cxl.mem read request (e.g., one or more cxl.mem read requests from the host 305, where the read request is associated with data in the DRAM 370).

[0116] At operation 510, method 500 may include performing one or more operations on metadata corresponding to data associated with the read request (e.g., data of DRAM 370) (e.g., based on an incoming CXL.mem read request). For example, based on the read request, PMEM controller 325 (e.g., metadata processor 360) may increment host request counter 450 (e.g., host request counter++) and / or increment age counter 430 (e.g., age counter++). Additionally or alternatively, based on the read request, PMEM controller 325 (e.g., metadata processor 360) may update the hot bit value associated with the data bound to the read request (e.g., of hot bitmap 425). In some cases, PMEM controller 325 may update the hot bit value based on age counter 430 and / or heat threshold 455 (e.g., hot bit = age counter > heat threshold). For example, when age counter 430 exceeds (e.g., is greater than or greater than or equal to) heat threshold 455, the hot bit may be set to binary 1. In some cases, when age counter 430 is less than (e.g., is less than or less than or equal to) heat threshold 455, the hot bit may be set to binary 0. Additionally or alternatively, based on the read request, PMEM controller 325 (e.g., metadata processor 360) may update total hot data counter 440 based on the hot bit (e.g., based on hot bit = age counter > heat threshold) and the previous value of the hot bit (e.g., total hot data counter += hot bit & ~old hot bit). For example, in the case where the hot bit (e.g., based on age counter 430 exceeding heat threshold 455) is set to binary 1, then total hot data counter 440 may be set to the value of the hot bit (e.g., binary 1) and the value of the old hot bit. In some cases, total hot data counter 440 may be incremented by the value of the hot bit. And then based on the read request, update metadata (e.g., metadata 365) correspondingly (e.g., update in SRAM 405 and / or register 415).

[0117] Figure 6 A flowchart depicting an example method 600 associated with the disclosed system according to example embodiments described herein. Method 600 illustrates an example flow for a write request based on background eviction for low-latency GPF. In some configurations, method 600 may be performed by Figure 1 PMEM controller 140 of Figure 2 PMEM controller 230 of and / or Figure 3Implementation of the PMEM controller 325. In some examples, one or more aspects of method 600 may be performed by and / or in conjunction with one or more components of the PMEM controller 325 (e.g., arbiter 335, eviction requester 340, GPF controller 345, data controller 355, metadata processor 360, DRAM 370, persistent memory 375, etc.). In some configurations, method 600 may be implemented in conjunction with machine 105, components of machine 105, or any combination thereof. The depicted method 600 is merely one implementation, and one or more operations of method 600 may be rearranged, reordered, omitted, and / or otherwise modified such that other implementations are possible and expected.

[0118] At operation 605, method 600 may include receiving an incoming write request. For example, the PMEM controller 325 may receive an incoming cxl.mem write request (e.g., one or more cxl.mem write requests from host 305, where the write request is associated with data in DRAM 370).

[0119] At operation 610, method 600 includes performing one or more operations on metadata corresponding to data associated with the write request (e.g., data in DRAM 370) (e.g., based on the incoming CXL.mem write request). For example, based on the write request, the PMEM controller 325 (e.g., metadata processor 360) may increment the host request counter 450 (e.g., host request counter++) and / or increment the age counter 430 (e.g., age counter++). Additionally or alternatively, based on the write request, the PMEM controller 325 (e.g., metadata processor 360) may update the dirty bit value of the dirty bitmap 420 (e.g., for data associated with the write request, dirty bit = 1). Additionally or alternatively, based on the write request, the PMEM controller 325 (e.g., metadata processor 360) may update the total dirty data counter 435 based on the dirty bit (e.g., based on setting dirty bit = 1) and the previous value of the dirty bit (e.g., total dirty bit counter += dirty bit & ~old dirty bit (i.e., &~ means: the old dirty bit is first inverted and then ANDed with the dirty bit)). Thus, based on the write request, the metadata (e.g., metadata 365) is updated.

[0120] Figure 7 The figure shows a flowchart depicting an example method 700 associated with the disclosed system according to example embodiments described herein. Method 700 shows an example flow of background eviction requests according to background eviction-based low-latency GPF. In some configurations, method 700 may be performed by Figure 1 the PMEM controller 140, Figure 2 the PMEM controller 230, and / or Figure 3It is implemented by the PMEM controller 325. In some examples, one or more aspects of method 700 may be performed by and / or in conjunction with one or more components of the PMEM controller 325 (e.g., arbiter 335, eviction requester 340, GPF controller 345, data controller 355, metadata processor 360, DRAM 370, persistent memory 375, etc.). In some configurations, method 700 may be implemented in conjunction with machine 105, components of machine 105, or any combination thereof. The depicted method 700 is merely one implementation, and one or more operations of method 700 may be rearranged, reordered, omitted, and / or otherwise modified such that other implementations are possible and contemplated.

[0121] At operation 705, method 700 may include receiving one or more background eviction requests. For example, the PMEM controller 325 may be configured to receive at least one background eviction request. In some cases, one or more background eviction requests may be generated by the eviction requester 340 (e.g., based on metadata 365 and / or requests from the host 305).

[0122] At operation 710, method 700 may include performing one or more operations on the metadata corresponding to the data associated with the background eviction request (e.g., data in DRAM 370). For example, based on the background eviction request, the PMEM controller 325 (e.g., metadata processor 360) may update the dirty bit of the data associated with the received background eviction request (e.g., based on the data being evicted, dirty bit = 0). Additionally or alternatively, based on the background eviction request, the PMEM controller 325 (e.g., metadata processor 360) may decrement the total dirty bit counter (e.g., based on the data being evicted, total dirty bit counter--). Additionally or alternatively, based on the background eviction request, the PMEM controller 325 (e.g., metadata processor 360) may update the total hot data counter 440 (e.g., total hot data counter -= hot bit). Additionally or alternatively, based on the background eviction request, the PMEM controller 325 (e.g., metadata processor 360) may update the age counter 430 (e.g., based on the data being evicted, age counter = 0). Additionally or alternatively, based on the background eviction request, the PMEM controller 325 (e.g., metadata processor 360) may update the hot bit associated with the data (e.g., based on the data being evicted, hot bit = 0). Thus, based on the background eviction request, the metadata is updated.

[0123] Figure 8 The depicted figure shows a flowchart of an example method 800 associated with the disclosed system according to example embodiments described herein. Method 800 shows an example GPF request method based on the systems and methods described herein. In some configurations, method 800 may be implemented by Figure 1the PMEM controller 140, Figure 2 the PMEM controller 230, and / or Figure 3 the PMEM controller 325. In some examples, one or more aspects of method 800 may be performed by and / or in conjunction with one or more components of PMEM controller 325 (e.g., arbiter 335, eviction requester 340, GPF controller 345, data controller 355, metadata processor 360, DRAM 370, persistent memory 375, etc.). In some configurations, method 800 may be implemented in conjunction with machine 105, components of machine 105, or any combination thereof. The depicted method 800 is merely one implementation, and one or more operations of method 800 may be rearranged, reordered, omitted, and / or otherwise modified such that other implementations are possible and contemplated.

[0124] At operation 805, method 800 may include monitoring GPF request monitoring. For example, PMEM controller 325 (e.g., in conjunction with GPF controller 345) may be configured to monitor GPF requests.

[0125] At operation 810, method 800 may include detecting one or more GPF requests. For example, eviction requester 340 and / or host 305 may generate one or more GPF requests. In some cases, GPF controller 345 may detect one or more GPF requests based on monitoring GPF requests by the GPF controller.

[0126] At operation 815, method 800 may include determining whether a dirty data counter (e.g., total dirty data counter 435) is greater than zero. When metadata processor 360 determines that the dirty data counter is not greater than zero (e.g., total dirty data counter 435 equals zero, indicating completion of GPF requests), then method 800 returns to operation 805, where GPF controller 345 returns to monitoring GPF requests (e.g., the trigger for monitoring GPF requests). When metadata processor 360 determines that the dirty data counter is greater than zero, then method 800 proceeds to operation 820.

[0127] At operation 820, method 800 may include eviction requester 340 reading dirty bitmap metadata and sending eviction requests for a given metadata row or dirty pages in a metadata row (e.g., for all dirty pages in each metadata row).

[0128] At operation 825, method 800 may include PMEM controller 325 (e.g., metadata processor 360) updating the dirty data counter (e.g., dirty data counter -= the number of dirty data pages in the metadata row).

[0129] Figure 9The flowchart depicts an example method 900 associated with the disclosed system according to the example embodiments described herein. Method 900 illustrates a background eviction request method based on the systems and methods described herein. In some configurations, method 900 may be implemented by Figure 1 the PMEM controller 140 of Figure 2 the PMEM controller 230 of, and / or Figure 3 the PMEM controller 325 of. In some examples, one or more aspects of method 800 may be performed by and / or in conjunction with one or more components of PMEM controller 325 (e.g., arbiter 335, eviction requester 340, GPF controller 345, data controller 355, metadata processor 360, DRAM 370, persistent memory 375, etc.). In some configurations, method 900 may be implemented in conjunction with machine 105, components of machine 105, or any combination thereof. The depicted method 900 is merely one embodiment, and one or more operations of method 900 may be rearranged, reordered, omitted, and / or otherwise modified such that other embodiments are possible and contemplated.

[0130] At operation 905, method 900 may include monitoring background eviction requests. For example, PMEM controller 325 (e.g., in conjunction with GPF controller 345) may be configured to monitor background eviction requests.

[0131] At operation 910, method 900 may include detecting one or more background eviction requests. For example, PMEM controller 325 (e.g., GPF controller 345) may be configured to detect one or more background eviction requests based on the monitoring. In some examples, eviction requester 340 and / or host 305 may generate one or more background eviction requests. In some cases, eviction requester 340 may generate one or more background eviction requests based on inputs from GPF controller 345 and / or metadata processor 360.

[0132] At operation 915, method 900 may include determining whether a dirty data counter (e.g., total dirty data counter 435) is greater than an eviction threshold (e.g., eviction threshold 445). When PMEM controller 325 determines that the dirty data counter is not greater than the eviction threshold (e.g., total dirty data counter 435 is less than or equal to the eviction threshold, indicating completion of the eviction request), then method 900 returns to monitoring background eviction requests (e.g., the trigger for monitoring background eviction requests) at operation 905. When PMEM controller 325 determines that the dirty data counter is greater than the eviction threshold, then method 900 may proceed to operation 920.

[0133] At operation 920, method 900 may include the eviction requester 340 reading dirty bitmap metadata (e.g., reading an entry of the dirty bitmap 420 of data associated with a background eviction request). In some cases, the eviction requester 340 may generate an eviction request for a dirty page (e.g., each dirty page) having a hot bit == 0 (e.g., for each metadata row).

[0134] At operation 925, method 900 may include processing the eviction request and response. For example, the arbiter 335 may be configured to process the eviction request and the response to each eviction request (e.g., denying the request or granting the request). When the arbiter 335 grants the request, the arbiter 335 may allow the request to proceed to the data controller 355 that executes the request.

[0135] At operation 930, method 900 may include performing one or more operations based on the processing of the eviction request at operation 925. For example, the PMEM controller 325 (e.g., the metadata processor 360) may be configured to update the dirty data counter based on the processing of the background eviction request (e.g., dirty data counter -= the number of dirty data pages in the metadata row).

[0136] Figure 10 A flowchart depicting an example method 1000 associated with the disclosed system according to example embodiments described herein. In some configurations, method 1000 may be implemented by Figure 1 the PMEM controller 140, Figure 2 the PMEM controller 230, and / or Figure 3 the PMEM controller 325. In some configurations, method 1000 may be implemented in conjunction with machine 105, components of machine 105, or any combination thereof. The depicted method 1000 is merely one implementation, and one or more operations of method 1000 may be rearranged, reordered, omitted, and / or otherwise modified such that other implementations are possible and contemplated.

[0137] At operation 1005, method 1000 may include generating metadata based on monitoring data in volatile memory. For example, the PMEM controller 325 may generate metadata based on the PMEM controller 325 monitoring data in volatile memory.

[0138] At operation 1010, method 1000 may include triggering an eviction request for evicting data in volatile memory based on the metadata. For example, the PMEM controller 325 may trigger an eviction request for evicting data in volatile memory based on the PMEM controller 325 analyzing the metadata.

[0139] At operation 1015, method 1000 may include processing an eviction request by forwarding the eviction request to a data controller based on an analysis of the eviction request in response to request criteria. For example, PMEM controller 325 may analyze the eviction request relative to the request criteria and provide the eviction request to the data controller for processing based on the analysis.

[0140] Figure 11 A flowchart depicting an example method 1100 associated with the disclosed system in accordance with example embodiments described herein. In some configurations, method 1100 may be implemented by Figure 1 PMEM controller 140, Figure 2 PMEM controller 230, and / or Figure 3 PMEM controller 325. In some configurations, method 1100 may be implemented in conjunction with machine 105, components of machine 105, or any combination thereof. The depicted method 1100 is merely one implementation, and one or more operations of method 1100 may be rearranged, reordered, omitted, and / or otherwise modified such that other implementations are possible and contemplated.

[0141] At operation 1105, method 1100 may include generating metadata based on monitoring data in volatile memory. For example, PMEM controller 325 may generate metadata based on PMEM controller 325 monitoring data in volatile memory.

[0142] At operation 1110, method 1100 may include triggering an eviction request for evicting data in volatile memory based on the metadata. For example, PMEM controller 325 may analyze the metadata and trigger an eviction request for evicting data in volatile memory based on the analysis.

[0143] At operation 1115, method 1100 may include processing an eviction request by forwarding the eviction request to a data controller based on an analysis of the eviction request relative to request criteria. For example, PMEM controller 325 may analyze the eviction request relative to the request criteria and provide the eviction request to the data controller for processing based on the analysis.

[0144] At operation 1120, method 1100 may include moving data to a persistent storage device based on device idle time. For example, processing the eviction request may include PMEM controller 325 moving data to a persistent storage device based on device idle time.

[0145] In the examples described herein, the configurations and operations are example configurations and operations and may involve various additional configurations and operations not explicitly shown. In some examples, one or more aspects of the configurations and / or operations shown may be omitted. In some embodiments, one or more of the operations may be performed by components other than those shown herein. Additionally or optionally, the order and / or temporal order of the operations may be changed.

[0146] Certain embodiments may be implemented in one or a combination of hardware, firmware, and software. Other embodiments may be implemented as instructions stored on a computer-readable storage device that may be read and executed by at least one processor to perform the operations described herein. The computer-readable storage device may include any non-transitory memory mechanism for storing information in a form readable by a machine (e.g., a computer). For example, the computer-readable storage device may include read-only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, and other storage devices and media.

[0147] The term "exemplary" is used herein to mean "serving as an example, instance, or illustration". Any embodiment described herein as "exemplary" need not be construed as preferred or advantageous over other embodiments. As used herein, the terms "computing device", "user device", "communication station", "station", "handheld device", "mobile device", "wireless device", and "user equipment (UE)" refer to a wireless communication device (such as, a cellular phone, a smartphone, a tablet computer, a netbook, a wireless terminal, a laptop computer, a femtocell, a high data rate (HDR) user station, an access point, a printer, a point-of-sale device, an access terminal, or other personal communication system (PCS) device). The device may be mobile or fixed.

[0148] As used in this document, the term "communicate" is intended to include both sending or receiving or both sending and receiving. This can be particularly useful in claims when describing the organization of data being sent by one device and received by another device but only requiring the functionality of one of those devices to infringe the claim. Similarly, when only the functionality of one of those devices is being claimed, the two-way exchange of data between the two devices (where the two devices send and receive during the exchange) may be described as "transmitting". As used herein, the term "transmit" with respect to a wireless communication signal includes sending a wireless communication signal and / or receiving a wireless communication signal. For example, a wireless communication unit capable of transmitting a wireless communication signal may include a wireless transmitter for sending the wireless communication signal to at least one other wireless communication unit and / or a wireless communication receiver for receiving a wireless communication signal from at least one other wireless communication unit.

[0149] Some embodiments may be used in conjunction with a variety of devices and systems such as, for example, personal computers (PCs), desktop computers, mobile computers, laptop computers, notebook computers, tablet computers, server computers, handheld computers, handheld devices, personal digital assistant (PDA) devices, handheld PDA devices, in-vehicle devices, out-of-vehicle devices, hybrid devices, vehicle devices, non-vehicle devices, mobile or portable devices, consumer devices, non-mobile or non-portable devices, wireless communication stations, wireless access points (APs), wired or wireless routers, wired or wireless modems, video devices, audio devices, audio-video (A / V) devices, wired or wireless networks, wireless local area networks, wireless video area networks (WVANs), local area networks (LANs), wireless LANs (WLANs), personal area networks (PANs), wireless PANs (WPANs), etc.

[0150] Some embodiments may be used in conjunction with one-way and / or two-way radio communication systems, cellular radiotelephone communication systems, mobile phones, cellular phones, wireless phones, personal communication system (PCS) devices, PDA devices incorporating wireless communication devices, mobile or portable global positioning system (GPS) devices, devices incorporating GPS receivers or transceivers or chips, devices incorporating RFID elements or chips, multiple-input multiple-output (MIMO) transceivers or devices, single-input multiple-output (SIMO) transceivers or devices, multiple-input single-output (MISO) transceivers or devices, devices having one or more internal antennas and / or external antennas, digital video broadcast (DVB) devices or systems, multi-standard radio devices or systems, wired or wireless handheld devices (such as smart phones), wireless application protocol (WAP) devices, etc.

[0151] Some embodiments may be used in conjunction with one or more wireless communication protocols such as, for example, radio frequency (RF), infrared (IR), frequency division multiplexing (FDM), orthogonal FDM (OFDM), time division multiplexing (TDM), time division multiple access (TDMA), extended TDMA (E-TDMA), general packet radio service (GPRS), extended GPRS, code division multiple access (CDMA), wideband CDMA (WCDMA), CDMA 2000, single-carrier CDMA, multi-carrier CDMA, multi-carrier modulation (MDM), discrete multi-tone (DMT), Bluetooth TM , Global Positioning System (GPS), Wi-Fi, Wi-Max, ZigBee TM、used in combination with one or more types of wireless communication signals and / or systems such as ultra-wideband (UWB), Global System for Mobile Communications (GSM), 2G, 2.5G, 3G, 3.5G, 4G, fifth-generation (5G) mobile networks, 3GPP, Long-Term Evolution (LTE), Advanced LTE, Enhanced Data Rates for GSM Evolution (EDGE), etc. Other embodiments may be used in a variety of other devices, systems, and / or networks.

[0152] Although example processing systems have been described above, embodiments of the subject matter and functional operations described herein may be implemented in other types of digital electronic circuitry or in computer software, firmware, or hardware (including the structures disclosed in this specification and their structural equivalents) or in combinations of one or more of them.

[0153] Embodiments of the subject matter and operations described herein may be implemented in digital electronic circuitry or in computer software, firmware, or hardware (including the structures disclosed in this specification and their structural equivalents) or in combinations of one or more of them. Embodiments of the subject matter described herein may be implemented as one or more computer programs (i.e., one or more components of computer program instructions) encoded on a computer storage medium for execution by, or to control the operation of, an information / data processing apparatus. Optionally or additionally, the program instructions may be encoded on an artificially generated propagated signal (e.g., a machine-generated electrical, optical, or electromagnetic signal) that is generated to encode information / data for transmission to a suitable receiver apparatus for execution by the information / data processing apparatus. A computer storage medium may be a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them, or may be included in a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them. Moreover, although a computer storage medium is not a propagated signal, a computer storage medium may be the source or destination of computer program instructions encoded in an artificially generated propagated signal. A computer storage medium may also be one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices), or may be included in one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices).

[0154] The operations described herein may be implemented as operations performed by an information / data processing apparatus on information / data stored on one or more computer-readable storage devices or received from other sources.

[0155] The term "data processing apparatus" includes all kinds of devices, apparatuses and machines for processing data, including, for example, programmable processors, computers, system-on-chips, or multiple or combinations of the foregoing. The apparatus may include dedicated logic circuitry (e.g., FPGAs (field programmable gate arrays) or ASICs (application specific integrated circuits)). In addition to hardware, the apparatus may also include code that creates an execution environment for the computer programs under discussion (e.g., code that constitutes processor firmware, protocol stacks, database management systems, operating systems, cross-platform runtime environments, virtual machines, or combinations of one or more of them). The apparatus and the execution environment may implement various different computing model infrastructures (such as, network services, distributed computing, and grid computing infrastructures).

[0156] A computer program (also called a program, software, software application, script, or code) can be written in any form of a programming language (including compiled or interpreted languages, declarative or procedural languages), and it can be deployed in any form (including as a stand-alone program or as a component, subroutine, object, or other unit suitable for use in a computing environment). A computer program may or may not correspond to a file in a file system. The program may be stored in a portion of a file that holds other programs or information / data (e.g., one or more scripts stored in a markup language document), stored in a single file dedicated to the program under discussion, or stored in multiple coordinated files (e.g., files that store one or more components, subroutines, or portions of code). A computer program may be deployed to execute on one computer or on multiple computers located at one site or distributed across multiple sites and interconnected by a communication network.

[0157] The processing and logical flows described herein can be executed by one or more programmable processors that execute one or more computer programs to perform actions by operating on input information / data and generating output. By way of example, processors suitable for executing computer programs include both general and special purpose microprocessors as well as any one or more processors of any kind of digital computer. In general, a processor will receive instructions and information / data from a read only memory or a random access memory or both. Essential elements of a computer are a processor for performing actions in accordance with instructions and one or more memory devices for storing the instructions and data. In general, a computer will also include one or more mass storage devices for storing data (e.g., magnetic disks, magneto-optical disks, or optical disks) or operatively coupled to receive information / data from one or more mass storage devices for storing data or to transfer information / data to one or more mass storage devices for storing data or both. However, a computer need not have such devices. Devices suitable for storing computer program instructions and information / data include all forms of non-volatile memory, media, and memory devices, by way of example, non-volatile memory, media, and memory devices include semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices); magnetic disks (e.g., internal hard disks or removable disks); magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and memory may be supplemented by, or incorporated in, special purpose logic circuitry.

[0158] To provide for interaction with a user, embodiments of the subject matter described herein can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information / data to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer. Other kinds of devices can also be used to provide for interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic, speech, or tactile input). In addition, for example, a computer can interact with a user by sending a web page to the user's client device in response to a request received from a web browser, by sending files to and receiving files from the device the user uses.

[0159] Embodiments of the subject matter described herein can be implemented in a computing system that includes backend components (e.g., as an information / data server), or that includes middleware components (e.g., an application server), or that includes frontend components (e.g., a client computer having a graphical user interface or a web browser through which a user can interact with embodiments of the subject matter described herein) or any combination of one or more such backend components, middleware components, or frontend components. The components of the system can be interconnected by any form or medium of digital information / data communication (e.g., a communication network). Examples of communication networks include local area networks (“LANs”) and wide area networks (“WANs”), the Internet (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

[0160] The computing system can include clients and servers. The clients and servers are typically remote from each other and generally interact via a communication network. The relationship of client and server arises by virtue of computer programs running on respective computers and having a client-server relationship to each other. In some embodiments, the server sends information / data (e.g., an HTML page) to the client device (e.g., for purposes of displaying the information / data to a user interacting with the client device and receiving user input from the user interacting with the client device). Information / data generated at the client device (e.g., results of user interaction) can be received at the server from the client device.

[0161] Although this specification contains many specific implementation details, these should not be construed as limitations on the scope of any embodiment or of what can be claimed, but rather as descriptions of features specific to particular embodiments. The particular features described herein in the context of separate embodiments can also be implemented in combination within a single embodiment. Conversely, the various features described in the context of a single embodiment can also be implemented separately or in any suitable sub-combination in multiple embodiments. Moreover, although the features may be described above as acting in particular combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excluded from the combination, and the claimed combination can be directed to a sub-combination or a variation of a sub-combination.

[0162] Similarly, although the operations are depicted in the drawings in a particular order, this should not be understood as requiring that the operations be performed in the particular order shown or in a sequential order, or that all of the illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Additionally, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0163] Accordingly, specific embodiments of the subject matter have been described. Other embodiments are within the scope of the appended claims. In some instances, the acts recited in the claims can be performed in a different order and still achieve the desired result. Further, the processes depicted in the figures need not be in the particular order or sequential order shown to achieve the desired result. In certain embodiments, multitasking and parallel processing may be advantageous.

[0164] Benefiting from the foregoing description and the teachings presented in the related drawings, those skilled in the art to which these embodiments pertain will envision many modifications and other examples of the embodiments described herein. Accordingly, it is to be understood that the embodiments are not limited to the specific embodiments disclosed, and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

1. A persistent memory controller for memory management, the persistent memory controller comprising: A metadata controller configured to generate metadata based on monitoring data in volatile memory; A memory manager configured to generate a request for removing the data in volatile memory based on the metadata; And A data controller configured to process the request based on an arbiter granting the request according to a request criterion and the arbiter allowing the request to go to the data controller.

2. The persistent memory controller according to claim 1, wherein, The step of the data controller processing the request includes the data controller moving the data based on the device idle time.

3. The persistent memory controller according to claim 1, wherein, The request criterion is based on the priority of the request and the priority of the host request.

4. The persistent memory controller according to claim 1, wherein, The request criterion is based on the pattern of the data in volatile memory.

5. The persistent memory controller as claimed in claim 1, wherein, The request criterion is based on at least one of the following: The age of the data in volatile memory, The heat of the data in volatile memory, and A selection process for selecting the request.

6. The persistent memory controller according to claim 1, wherein, The request criterion is based on the number of requests at the memory manager and the number of requests at the host.

7. The persistent memory controller according to claim 1, wherein, The request criterion is based on the frequency of requests at the memory manager and the frequency of requests at the host.

8. The persistent memory controller according to claim 1, wherein, The request criterion is based on the memory manager determining the state of the host.

9. The persistent memory controller according to claim 1, wherein, The metadata includes at least one of the following: The dirty state of the data in volatile memory, The age of the data in volatile memory, and Register metadata including at least one of a dirty data count, a hot data count, a host request count, an eviction threshold, and a data heat threshold.

10. The persistent memory controller according to claim 1, wherein, The metadata describes the data in volatile memory.

11. A method for memory management via at least one processor of one or more processors, the method comprising: Generating metadata based on monitoring data in volatile memory; Generating a request for removing the data in volatile memory based on the metadata; And Processing the request based on the request being allowed to go to the data controller in response to the request being granted based on a request criterion.

12. The method according to claim 11, wherein The step of processing the request includes moving the data based on the device idle time.

13. The method according to claim 11, wherein, The request criterion is based on at least one of the following: The priority of the request and the priority of the host request, and The pattern of the data in volatile memory.

14. The method according to claim 11, wherein, The request criterion is based on at least one of the following: The age of the data in volatile memory, The heat of the data in volatile memory, and A selection process for selecting the request.

15. The method according to claim 11, wherein The request criterion is based on the number of requests at the memory manager and the number of requests at the host.

16. The method according to claim 11, wherein, The request criterion is based on at least one of the following: The frequency of requests at the memory manager and the frequency of requests at the host, and Determining that the host is in an idle state.

17. The method according to claim 11, wherein, The metadata includes at least one of the following: The dirty state of the data in volatile memory, The age of the data in volatile memory, and Register metadata including at least one of a dirty data count, a hot data count, a host request count, an eviction threshold, and a data heat threshold.

18. A non-transitory computer readable medium storing code, the code comprising instructions executable by at least one processor of a device to: generating metadata based on monitoring data in the volatile memory; generating a request to remove the data in the volatile memory based on the metadata; and The request is allowed to proceed to a data controller to process the request based on the request in response to granting the request based on request criteria.

19. The non-transitory computer-readable medium according to claim 18, wherein, The step of processing the request is based on further instructions executable by the at least one processor of the device to move the data during an idle time of the device.

20. The non-transitory computer-readable medium according to claim 18, wherein, The request criteria is based on at least one of the following: the priority of the request and the priority of the host request, the pattern of said data in volatile memory, the age of the data in volatile memory, and The temperature of the data in the volatile memory.

Images