A memory system for binding data to memory namespaces

By storing and using metadata in a computer system to identify the delay of different memory devices, the processor and operating system dynamically adjust memory allocation, solving the delay problem caused by slow memory mapping of processors, improving system response speed and processing efficiency.

CN114402291BActive Publication Date: 2025-09-02MICRON TECHNOLOGY INC
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
CN202080064626.2
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2019-09-17
Filing Date
2020-09-16
Publication Date
2025-09-02
Estimated Expiration
2040-09-16

AI Technical Summary

Technical Problem

Existing computer systems are unable to effectively detect the mapping delay of different memory devices, resulting in delays in processors due to slow memory access, especially when mapping virtual address ranges to slow physical memory devices.

Method used

By storing and using metadata in a computer system to identify the delays of different memory devices, processors and operating systems can dynamically adjust memory allocations based on the priority and context of the processor, ensuring that high-priority processors run in fast memory.

Benefits of technology

It effectively avoids the delay caused by slow memory access by the processor, and improves the system's response speed and processing efficiency.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114402291B_ABST
    Figure CN114402291B_ABST
Patent Text Reader

Abstract

The present invention provides a computer system comprising different types of physical memory devices that store randomly accessible data in the computer system's main memory. In one approach, an operating system allocates memory from a namespace for use by an application. The namespace is a logical reference to a physical memory device in which physical addresses are defined. The namespace is bound to a memory type. In response to binding the namespace to the memory type, the operating system adjusts a page table to map logical memory addresses in the namespace to memory devices of the memory type.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] Related applications

[0002] This application claims priority to U.S. patent application No. 16 / 573,535, filed on September 17, 2019, and entitled “MEMORY SYSTEM FOR BINDING DATA TO A MEMORY NAMESPACE,” the entire disclosure of which is hereby incorporated by reference herein. Technical Field

[0003] At least some embodiments disclosed herein relate generally to memory systems, and more particularly, but not limited to, memory systems for binding data to namespaces. Background Art

[0004] Various types of memory devices can be used to store data in the main memory of a computer system. One type of volatile memory device is a dynamic random access memory (DRAM) device. Various types of nonvolatile memory devices can include NAND flash memory devices or nonvolatile random access memory (NVRAM) devices.

[0005] In an operating system, memory management is responsible for managing the computer system's main memory. Memory management tracks the status of memory locations in main memory (e.g., allocated or free memory status). Memory management further determines the allocation of memory among the various programs running on the operating system. When allocating memory to a program, the operating system determines the memory location to be assigned to the program.

[0006] In one approach, operating systems use paging to divide main memory into fixed-size units called page frames. A software program's virtual address space is divided into pages of equal size. A hardware memory management unit maps the pages to the frames in physical memory. In a paged memory management approach, each program typically runs in its own address space.

[0007] In some cases, a memory management unit (MMU) is referred to as a paged memory management unit (PMMU). The MMU manages all memory references used by the operating system and performs translation of virtual memory addresses to physical addresses. The MMU typically divides the virtual address space (which is the range of addresses used by the processor) into pages.

[0008] In some implementations, the MMU uses a page table containing page table entries to map virtual page numbers to physical page numbers in main memory. In some cases, a cache of page table entries, called a translation lookaside buffer (TLB), is used to avoid the need to access the page table stored in main memory when mapping virtual addresses. When virtual memory is used, a contiguous range of virtual addresses can be mapped to several non-contiguous blocks of physical memory.

[0009] In some cases, a page table entry may include information about the page's usage. Examples include whether data has been written to the page, when the page was last used, the types of processes that can read and write the page (e.g., user mode or supervisor mode), and whether the page should be cached.

[0010] In one approach, the TLB is implemented as a content-addressable memory (CAM). The search key is a virtual address, and the search result is a physical address. If the requested address is in the TLB, the physical address retrieved from the search is used to access the physical memory device. If the requested address is not in the TLB, the page table is accessed in main memory.

[0011] In some cases, the virtual memory management system uses a handler identifier to associate each page with a handler. The association of a handler identifier with a virtual page can help select pages for page-out. For example, if a handler's primary code page has been paged out, the likelihood that other pages belonging to that handler will be needed immediately is reduced.

[0012] More generally, a computer system may have one or more memory subsystems. A memory subsystem may be a memory module, such as a dual in-line memory module (DIMM), a small outline DIMM (SO-DIMM), or a non-volatile dual in-line memory module (NVDIMM). A memory subsystem may include one or more memory components that store data. Memory components may be, for example, non-volatile memory components and volatile memory components. Examples of memory components include memory integrated circuits. Some memory integrated circuits are volatile and require power to maintain stored data. Some memory integrated circuits are non-volatile and can retain stored data even when power is not supplied. Examples of non-volatile memory include flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), and electrically erasable programmable read-only memory (EEPROM), among others. Examples of volatile memory include dynamic random access memory (DRAM) and static random access memory (SRAM). Generally speaking, a computer system may utilize a memory subsystem to store data at and retrieve data from memory components.

[0013] For example, a computer system may include one or more memory subsystems attached to the computer system. The computer system may have a central processing unit (CPU) that communicates with the one or more memory subsystems to store and / or retrieve data and instructions. Instructions for the computer may include an operating system, device drivers, and application programs. The operating system manages resources in the computer and provides common services to application programs, such as memory allocation and time sharing of resources. Device drivers operate or control specific types of devices in the computer; and the operating system uses device drivers to provide resources and / or services provided by those types of devices. The central processing unit (CPU) of the computer system may execute the operating system and device drivers to provide services and / or resources to application programs. The central processing unit (CPU) may execute applications that use the services and / or resources. For example, an application implementing a certain application type may instruct the central processing unit (CPU) to store data in and retrieve data from the memory components of the memory subsystem.

[0014] The operating system of a computer system allows application programs to store data in or retrieve data from memory components of one or more memory subsystems of the computer system using virtual addresses of memory. The operating system maps virtual addresses to physical addresses of one or more memory subsystems connected to the central processing unit (CPU) of the computer system. The operating system translates memory accesses specified at virtual addresses into physical addresses of the memory subsystems.

[0015] The virtual address space can be divided into pages. Pages of virtual memory can be mapped to pages of physical memory in the memory subsystem. An operating system can use paging techniques to access pages of memory in a storage device via pages of memory in a memory module. At different instances in time, the same virtual page of memory in a memory module can be used as a proxy to access different physical pages of memory in a storage device or another storage device in the computer system.

[0016] A computer system may include a hypervisor (or virtual machine monitor) to create or provide virtual machines. A virtual machine is a computing device that is virtually implemented using the resources and services available in the computer system. The hypervisor presents the virtual machine to the operating system as if the components of the virtual machine were dedicated physical components. A guest operating system runs in the virtual machine in a manner similar to a host operating system running in the computer system, managing the resources and services available to the virtual machine. The hypervisor allows multiple virtual machines to share the resources of the computer system and allows the virtual machines to operate largely independently of each other on the computer. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Embodiments are illustrated by way of example, and not limitation, in the figures of the accompanying drawings in which like references indicate similar elements.

[0018] Figure 1 An example computer system having a memory subsystem according to some embodiments is described.

[0019] Figure 2 A mobile device is shown using a memory bus to access different types of memory in a memory module according to some embodiments.

[0020] Figure 3 An example computer system is described that stores metadata used to access memory devices in a memory subsystem in accordance with some embodiments.

[0021] Figure 4 A memory module is shown configured for memory bus access of the memory module's volatile and non-volatile memory by a host computer system according to some embodiments.

[0022] Figure 5 A host operating system is shown accessing a memory module using memory bus access in accordance with at least some embodiments.

[0023] Figure 6 A method is presented according to some embodiments for managing memory for a processing program in an address space of a computer system based on stored metadata associating a virtual address range for the processing program in the address space with a physical address for a memory device in the computer system.

[0024] Figure 7 is a block diagram of an example computer system on which embodiments of the present invention may operate.

[0025] Figure 8 An example computer system is described that uses one or more page tables to access memory devices on a memory bus in accordance with some embodiments.

[0026] Figure 9 An example page table with page table entries is illustrated in accordance with some embodiments.

[0027] Figure 10 A method for generating page table entries to map virtual addresses of virtual pages to physical addresses in memory devices of different memory types is presented in accordance with some embodiments.

[0028] Figure 11 An example computer system is illustrated that uses a namespace table to map namespaces to different memory types of physical memory in the computer system in accordance with some embodiments.

[0029] Figure 12 An example namespace table having records mapping namespaces to different types of memory of a computer system is illustrated in accordance with some embodiments.

[0030] Figure 13 A method for binding data to a namespace in a memory system having physical memory of different memory types is presented according to some embodiments. DETAILED DESCRIPTION

[0031] At least some embodiments herein relate to a memory device that accesses stored metadata to identify stored data of a memory system. In various embodiments, as discussed herein, the metadata can be stored and accessed by various types of computer systems. In one example, the computer system is a system-on-chip (SoC) device that stores metadata for managing memory usage by one or more processing programs running on the SoC device. In one example, a mobile device uses the SoC device to manage the allocation of main memory to one or more applications running on the mobile device.

[0032] Other embodiments relate to page table entries that map virtual addresses of virtual pages to physical addresses in memory devices of different memory types. These embodiments are described in the section below entitled "Memory Type-Dependent Page Tables."

[0033] Other embodiments relate to binding data to a namespace in a memory system having physical memory of different memory types.These embodiments are described in the section below entitled "Binding Data to a Namespace".

[0034] Computer systems often use different types of memory devices to store data. One type of memory device commonly used is DRAM, which is generally considered to provide fast read and write access. DRAM is commonly used to store data in the main memory of a computer system.

[0035] Other memory devices, such as flash memory, are generally considered slower than DRAM. For example, the read or write access latency of DRAM is typically significantly less than the read or write access latency of flash memory. As a specific example, the write access latency of some memory devices can be tens or even hundreds of times greater than that of DRAM devices.

[0036] In previous computer systems that used different types of physical memory devices to store data in main memory, there was a technical problem in that the processor was unaware of how the memory used for various processing programs was actually mapped to the memory devices. For example, the processor could assign virtual address ranges to processing programs. However, the processor was unaware of how the virtual address ranges were mapped to different memory devices.

[0037] In one example, if a virtual address range for a processing program is mapped to a physical memory device (e.g., flash memory) that is significantly slower than other memory devices (e.g., DRAM), the processing program may be forced to run slowly because it cannot quickly access data from main memory that it needs to continue executing the processing program. For example, the processing program may need a response from main memory in order to continue data calculations or other processing (e.g., including data for a processor's read access request to main memory to obtain data required during execution by the processing program). If the required data from main memory is actually stored in the slow physical memory device, the processing is significantly delayed while waiting for the response.

[0038] Various embodiments of the present invention provide technical solutions to one or more of the above technical problems. In some embodiments, a computer system stores data regarding the latency of memory devices used by the computer system (e.g., memory devices used to provide main memory). In one example, the latency of various memory regions visible to the computer system's processor is known (e.g., represented by information collected and / or aggregated in stored metadata, as discussed below).

[0039] In some embodiments, the processor, operating system, and / or application (as programmed by a software designer) can be activated and / or performed by the computer system to avoid significant processing delays due to slow memory access. For example, a high-priority process requiring fast memory response can be configured to run in DRAM.

[0040] In another example, the priority of an application executing on the mobile device can be monitored. When the priority of an application increases (e.g., from low to high), the processor and / or operating system can automatically transfer the application out of the address range of main memory corresponding to the slow memory device and move the application to a new address range corresponding to the fast memory device.

[0041] In one example, memory device types include DRAM, NVRAM, and NAND flash memory. A handler's priority is determined by a processor (e.g., based on the handler's data usage pattern). Based on stored metadata regarding address ranges mapped to these memory device types, the processor assigns the handler to an address range with appropriate memory latency. For example, the processor may determine whether the handler has low, medium, or high priority. Based on determining that the handler has medium priority, software and / or data associated with the handler is stored in an address range corresponding to physical storage in the NVRAM memory device type, which has medium latency.

[0042] In one example, the NVRAM device type is 3D XPoint memory. In one example, the NVRAM device type can be resistive random access memory, magnetoresistive RAM, phase change RAM, and / or ferroelectric RAM. In one example, the NVRAM chip is used as the main memory of the computer system (e.g., NVDIMM-P). In one example, the NVRAM device is implemented using non-volatile 3D XPoint memory in a DIMM package.

[0043] In another example, if the processor and / or operating system is not configured to automatically transfer an application to a different address range in response to a priority change, the application's software code can itself be configured to read one or more values ​​from the stored metadata. Based on the read values, the application can manage data storage so that data is preferentially stored in the address range corresponding to the faster memory device. In one example, the application can determine the relative latency of available memory devices in the computer system based on reading or otherwise being provided with access to the stored metadata. In one example, the stored metadata specifies which data is on which memory device among various different memory devices having different latencies. By specifying the memory devices in this manner, the application can determine the latency of accessing specific data depending on the memory device being used to store the data.

[0044] In one example, an application on a mobile device reads the stored metadata when an allocation of main memory is requested by an operating system (e.g., executing on a system-on-chip device). In one example, the application makes a request for an address range in main memory that corresponds to a specific type of memory device and / or a specific latency associated with memory read or write accesses.

[0045] In one example, an application reads or otherwise accesses stored metadata to determine which memory is fast and which memory is slow. In a first context of the mobile device, the application requests allocation of fast memory. In a second context of the mobile device, the application requests allocation of slow memory. In one example, in response to detection of a predetermined context, the application initiates or requests a change in memory allocation. In one example, the application determines the change in context based on an updated query of stored metadata (e.g., by a processor) and / or data provided to the application by the computer system's processor (e.g., operating characteristics of the mobile device).

[0046] In one embodiment, a computer system includes a first memory device (e.g., DRAM) and a second memory device (e.g., NVRAM or NAND flash memory), and one or more processing devices (e.g., a CPU or a system on a chip (SoC)). The computer system further includes a memory containing instructions configured to instruct the one or more processing devices to: access memory in an address space maintained by an operating system, the access including accessing the first memory device and the second memory device using addresses in the address space; store metadata associating a first address range of the address space with the first memory device and a second address range of the address space with the second memory device; and manage, by the operating system, handlers including a first handler and a second handler based on the stored metadata, wherein data for the first handler is stored in the first memory device, and data for the second handler is stored in the second memory device.

[0047] In one embodiment, a computer system uses memory device types including DRAM, NVRAM, and NAND flash memory. In one example, DRAM is faster than NVRAM, which is faster than NAND flash memory. The computer system is configured so that all three different types of memory can be directly accessed by the computer system's processor using virtual memory addresses. In one example, the processor communicates with a memory management unit to implement a virtual-to-physical address mapping system.

[0048] In one embodiment, the application is not pre-programmed or otherwise configured to manage or handle optimization of memory allocation based on different types of memory devices. For example, this may occur for legacy software programs. In this type of situation, the operating system may be configured to manage optimization of memory allocation for the application.

[0049] In one example, the operating system detects or otherwise determines one or more characteristics of the application. Based on the characteristics, the operating system uses stored metadata to assign one or more address ranges in main memory to the application. In one example, the characteristics are determined based on information provided by the application itself (e.g., when the application is launched on the mobile device). In another example, the characteristics are provided by a computing device other than the computer system on which the application executes. In one example, a central repository is used to store and update a database or table of characteristics of the application. In one example, a central server provides the operating system with an indication of the type of physical memory to be used.

[0050] In one embodiment, the operating system determines a context associated with the execution of the computer system and / or application. Based on this context, the operating system assigns one or more address ranges in main memory to the application using stored metadata.

[0051] In one embodiment, the stored metadata is used to identify the device storing the data. A memory subsystem has multiple physical memory devices (e.g., DRAM, NVRAM, and NAND flash) that can be addressed by a processor (e.g., an SoC) in a memory address space. The metadata is used to specify which memory address regions are mapped to which physical memory devices. The metadata can be loaded into the DRAM and / or the processor (e.g., into the processor's cache) to determine which data is on which device and / or to estimate the latency of accessing the corresponding data.

[0052] In one embodiment, an application is executed on a mobile device having a processor that uses main memory. The application requests the mobile device's operating system to allocate a portion of the main memory for use by the application. The allocated memory is in a logical / virtual memory space (e.g., the memory addresses seen by the programmer and the execution units of the processor are virtual). In one embodiment, the virtual memory addresses are mapped to real / physical memory via a page table. A portion of the mapping data in the page table is cached in a buffer of the processor. In one example, the buffer is a translation lookaside buffer (TLB).

[0053] In one embodiment, a computer system includes DRAM, NVRAM, and NAND flash memory devices. The computer system's processor randomly accesses main memory by address. The addresses within the main memory correspond to the physical locations of data stored on these three types of memory devices. In one example, each of these devices is accessed by the processor using a synchronous memory bus. In one example, the DRAM is synchronous dynamic random access memory (SDRAM), which has an interface that is synchronous with the system bus that carries data between the CPU and the memory controller hub.

[0054] Figure 1An example computing environment 100 having a memory subsystem 110 is described according to some embodiments. Memory subsystem 110 may include media, such as memory components 109A-109N. Memory components 109A-109N may be volatile memory components, non-volatile memory components, or a combination thereof. In some embodiments, memory subsystem 110 is a memory module. Examples of memory modules include DIMMs and NVDIMMs. In some embodiments, memory subsystem 110 is a hybrid memory / storage subsystem. Generally speaking, computing environment 100 may include a computer system 120 that utilizes memory subsystem 110. For example, computer system 120 may write data to and read data from memory subsystem 110.

[0055] Computer system 120 may be a computing device, such as a mobile device, an IoT device, a desktop computer, a laptop computer, a network server, or any other computing device that includes memory and processing devices. Computer system 120 may include or be coupled to memory subsystem 110, such that computer system 120 can read data from or write data to memory subsystem 110. Computer system 120 may be coupled to memory subsystem 110 via a physical host interface. As used herein, "coupled to" generally refers to a connection between components, which may be an indirect or direct communication connection (e.g., without an intermediary component), wired or wireless, including, for example, electrical, optical, magnetic, etc. Examples of physical host interfaces include, but are not limited to, a Serial Advanced Technology Attachment (SATA) interface, a Peripheral Component Interconnect Express (PCIe) interface, a Universal Serial Bus (USB) interface, Fibre Channel, Serial Attached SCSI (SAS), a Double Data Rate (DDR) memory bus, etc. The physical host interface may be used to transfer data between computer system 120 and memory subsystem 110. When the memory subsystem 110 is coupled to the computer system 120 via a PCIe interface, the computer system 120 can further utilize an NVM Express (NVMe) interface to access the memory components 109A to 109N. A physical host interface can provide an interface for passing control, address, data, and other signals between the memory subsystem 110 and the computer system 120.

[0056] Figure 1 Memory subsystem 110 is described as an example. Generally speaking, computer system 120 can access multiple memory subsystems via a shared communication connection, multiple separate communication connections, and / or a combination of communication connections. In one example, each memory subsystem 110 can be a different type of memory device that is randomly accessed by processing device 118 via a memory bus.

[0057] Computer system 120 includes a processing device 118 and a controller 116. Processing device 118 may be, for example, a microprocessor, a central processing unit (CPU), a processing core of a processor, an execution unit, etc. In some cases, controller 116 may be referred to as a memory controller, a memory management unit, and / or an enabler. In one example, controller 116 controls communication via a bus coupled between computer system 120 and one or more memory subsystems 110.

[0058] In general, the controller 116 may send commands or requests to the memory subsystem 110 for desired access to the memory components 109A to 109N. The controller 116 may further include interface circuitry to communicate with the memory subsystem 110. The interface circuitry may convert responses received from the memory subsystem 110 into information for the computer system 120.

[0059] The controller 116 of the computer system 120 can communicate with the controller 115 of the memory subsystem 110 to perform operations such as reading, writing, or erasing data from the memory components 109A to 109N, as well as other such operations. In some cases, the controller 116 is integrated into the same package as the processing device 118. In other cases, the controller 116 is packaged separately from the processing device 118. The controller 116 and / or the processing device 118 may include hardware, such as one or more integrated circuits and / or discrete components, buffer memory, cache memory, or a combination thereof. The controller 116 and / or the processing device 118 may be a microcontroller, dedicated logic circuitry (e.g., a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.), or another suitable processor.

[0060] Memory components 109A-109N may include any combination of various different types of non-volatile memory components and / or volatile memory components. An example of a non-volatile memory component includes NAND-type flash memory. In one example, each of memory components 109A-109N may include one or more memory cell arrays, such as single-level cells (SLC) or multi-level cells (MLC) (e.g., triple-level cells (TLC) or quad-level cells (QLC)). In some embodiments, a particular memory component may include both SLC and MLC portions of memory cells. Each of the memory cells may store one or more data bits (e.g., a block of data) used by computer system 120.

[0061] While non-volatile memory components such as NAND-type flash memory are one example, memory components 109A-109N may be based on any other type of memory, such as volatile memory. In some embodiments, memory components 109A-109N may be, but are not limited to, random access memory (RAM), read-only memory (ROM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), phase change memory (PCM), magnetic random access memory (MRAM), spin transfer torque (STT)-MRAM, ferroelectric transistor random access memory (FeTRAM), ferroelectric RAM (FeRAM), conductive bridging RAM (CBRAM), resistive random access memory (RRAM), oxide-based RRAM (OxRAM), NOR flash memory, electrically erasable programmable read-only memory (EEPROM), nanowire-based non-volatile memory, memory incorporating memristor technology, and 3D XPoint arrays of non-volatile memory cells. The cross-point array of the nonvolatile memory can be combined with a stackable cross-grid data access array to store bits based on changes in bulk resistance. Furthermore, in contrast to many flash-based memories, cross-point nonvolatile memory can be written in place, where nonvolatile memory cells can be programmed without previously erasing them. Furthermore, the memory cells of memory components 109A-109N can be grouped into memory pages or data blocks, which can refer to memory component units used to store data.

[0062] The controller 115 of the memory subsystem 110 can communicate with the memory components 109A-109N to perform operations such as reading, writing, or erasing data at the memory components 109A-109N, as well as other such operations (e.g., in response to commands dispatched by the controller 116 on a command bus). The controller 115 may include hardware, such as one or more integrated circuits and / or discrete components, buffer memory, or a combination thereof. The controller 115 may be a microcontroller, dedicated logic circuitry (e.g., a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.), or another suitable processor. The controller 115 may include a processing device 117 (processor) configured to execute instructions stored in the local memory 119. In the illustrated example, the local memory 119 of the controller 115 includes embedded memory configured to store instructions for performing various processing programs, operations, logic flows, and routines for controlling the operation of the memory subsystem 110, including handling communications between the memory subsystem 110 and the computer system 120. In some embodiments, local memory 119 may include memory registers for storing memory pointers, fetched data, etc. Local memory 119 may also include read-only memory (ROM) for storing microcode. Figure 1 The example memory subsystem 110 in FIG. 1 has been described as including a controller 115, but in another embodiment of the present invention, the memory subsystem 110 may not include the controller 115 and may instead rely on external control (e.g., provided by an external host or by a processor or controller separate from the memory subsystem).

[0063] In general, the controller 115 may receive commands or operations from the computer system 120 and convert the commands or operations into instructions or appropriate commands to achieve the desired access to the memory components 109A-109N. The controller 115 may be responsible for other operations such as wear leveling operations, garbage collection operations, error detection and error correction code (ECC) operations, encryption operations, cache operations, and address conversion between logical block addresses and physical block addresses associated with the memory components 109A-109N. The controller 115 may further include host interface circuitry to communicate with the computer system 120 via a physical host interface. The host interface circuitry may convert commands received from the computer system into command instructions for accessing the memory components 109A-109N, and convert responses associated with the memory components 109A-109N into information for the computer system 120.

[0064] The memory subsystem 110 may also include additional circuitry or components not illustrated. In some embodiments, the memory subsystem 110 may include a cache or buffer 121 (e.g., DRAM or SRAM), and address circuitry (e.g., row decoders and column decoders) that can receive addresses from the controller 115 and decode the addresses to access the memory components 109A-109N.

[0065] The computing environment 100 includes a metadata component 113 in a computer system 120 that stores metadata identifying a memory device storing data (e.g., as discussed in various embodiments above). A portion of the metadata component 113 may reside on the computer system 120 and / or the memory subsystem 110. In one example, a portion of the metadata is stored in a local memory 119 and / or a buffer 121. In one example, a portion of the metadata is alternatively and / or additionally stored in a cache of the controller 116 (e.g., in a translation lookaside buffer).

[0066] In one example, the memory subsystem 110 can provide the computer system 120 with access to data in different types of memory devices via a DDR or other type of synchronous memory bus. In one embodiment, access is provided to data in NVRAM on the DIMMs and data in DRAM. In one example, the data is made accessible in the random access memory address space of the computer system 120 for access during host read / write requests via the DDR memory bus.

[0067] In one example, computer system 120 sends a page-in request (for access to a page) to controller 115. In response to receiving the page-in request, controller 115 moves a page from a slow medium (e.g., a non-volatile memory device) to a volatile memory device (e.g., DRAM on memory subsystem 110).

[0068] In one example, computer system 120 sends a page-out request to controller 115. In response to receiving the page-out request, controller 115 moves data from volatile memory (eg, DRAM on memory subsystem 110) to non-volatile memory via buffer 121.

[0069] In some embodiments, the controller 116 and / or the processing device 118 in the computer system 120 include at least a portion of the metadata component 113. For example, the controller 116 and / or the processing device 118 may include logic circuitry that implements the metadata component 113. For example, the processing device 118 (processor) of the computer system 120 may be configured to execute instructions stored in a memory for performing operations to identify devices in which data for the metadata component 113 is stored, as described herein. In some embodiments, the metadata component 113 is part of the operating system of the computer system 120, a device driver, or an application (e.g., an application executing on the computer system 120).

[0070] In some embodiments, controller 115 and / or processing device 117 in memory subsystem 110 include at least a portion of metadata component 113. For example, controller 115 and / or processing device 117 may include logic circuitry that implements metadata component 113.

[0071] In one example, a central processing unit (CPU) can access memory in a memory system connected to the CPU. For example, the central processing unit (CPU) can be configured to access memory based on a query of the stored metadata of the metadata component 113.

[0072] Figure 2A mobile device 200 is shown using a memory bus 203 to access different types of memory in a memory module 205 in accordance with some embodiments. Figure 2 Shows a computer system with different types of memory. Figure 2 The computer system includes a mobile device 200 and a memory module 205 connected to the mobile device 200 via a memory bus 203. The memory module 205 is Figure 1 An example of a memory subsystem 110 is illustrated in FIG.

[0073] The mobile device 200 includes a processing device 118, which may be a central processing unit or a microprocessor having one or more processing cores. The mobile device 200 may have a cache memory 211. At least a portion of the cache memory 211 may optionally be integrated into the same integrated circuit package as the processing device 118.

[0074] Figure 2 2 has multiple types of memory (e.g., 221 and 223). For example, type A memory 221 (e.g., DRAM) is faster than type B memory 223 (e.g., NVRAM). For example, memory bus 203 can be a double data rate bus. Generally, several memory modules (e.g., 205) can be coupled to memory bus 203.

[0075] The processing device 118 is configured via instructions (e.g., an operating system and / or one or more device drivers) to access a portion of memory in the computer system using the metadata component 113. For example, the processing device 118 may access the type B memory 223 (e.g., NVRAM) of the memory module 205 or the type A memory 221 (e.g., DRAM) of the memory module 205. In one embodiment, the type B memory 223 of the memory module 205 is only accessible by addressing the type A memory 221 of the memory module 205.

[0076] A controller 227 may be provided in the memory module 205 to manage data access to the type A memory 221 and the type B memory 223. In one embodiment, the controller 227 multiplexes access to the DRAM or NVRAM by the mobile device 200 and the memory module 205 when transferring data to or from the buffer 121. In one example, the memory bus 203 provides a host DDR channel as a DDR interface between the mobile device 200 and the memory module 205. In one example, once a page is retrieved from the NVRAM memory into the buffer 121, it can be loaded via a conventional DDR4 slot (e.g., a host DDR channel) for access by the mobile device.

[0077] In general, a memory subsystem (e.g., 205) may include media, such as memories (e.g., 221, ..., 223). Memories (e.g., 221, ..., 223) may include volatile memory, non-volatile memory (NVM), and / or a combination thereof. The processing device 118 may directly or indirectly write data to each of the memory subsystems (e.g., memory module 205) and read data from the memory subsystems (e.g., memory module 205).

[0078] In one embodiment, memory module 205 provides memory bus access to non-volatile memory or volatile memory by using buffer 121. In one example, memory module 205 is a DIMM coupled to mobile device 200 via a DDR bus. The storage medium is, for example, a cross point memory.

[0079] In one embodiment, the mobile device communicates with the memory module via a communication channel for read / write operations (e.g., using a DDR4 bus). The mobile device may have one or more central processing units (CPUs) that can be attached to computer peripheral devices such as the memory module via an interconnect, such as a computer bus (e.g., Serial AT Attachment (SATA), Peripheral Component Interconnect (PCI), PCI-Extended (PCI-X), PCI Express (PCIe)), a communication portion, and / or a computer network.

[0080] In one embodiment, the memory module can be used to store data for the processor in non-volatile or volatile storage media. The memory module has a host interface that implements communication with the mobile device using a communication channel. In one embodiment, the memory module 205 has a controller 227 that runs, for example, firmware, to operate in response to communications from the processing device 118. In one example, the memory module includes volatile dynamic random access memory (DRAM) and NVRAM. The DRAM and NVRAM store data accessible by the processing device 118 in a memory address space.

[0081] As explained, Figure 2 The processing device 118 may read data from or write data to a memory subsystem (eg, 205).

[0082] The physical host interface may be used to transfer data between the processing device 118 and the memory subsystem (eg, 205). The physical host interface may provide an interface for passing control, address, data, and other signals between the memory subsystem (eg, 205) and the processing device 118.

[0083] Generally speaking, a memory subsystem (e.g., memory module 205) includes a printed circuit board connected to a collection of memory devices (e.g., memory integrated circuits) that provide memory (e.g., 221, ..., 223). The memory (e.g., 221, ..., 223) on a memory subsystem (e.g., 205) can include any combination of different types of non-volatile memory devices and / or volatile memory devices.

[0084] In some implementations, the memory (e.g., 221, ..., 223) may include, but is not limited to, random access memory (RAM), read-only memory (ROM), dynamic random access memory (DRAM), static random access memory (SRAM), synchronous dynamic random access memory (SDRAM), phase change memory (PCM), magnetic random access memory (MRAM), or non-volatile (NOR) flash memory, electrically erasable programmable read-only memory (EEPROM), and / or a cross-point array of non-volatile memory cells.

[0085] The memory subsystem (e.g., memory module 205) may have a controller (e.g., 227) that communicates with the memory (e.g., 221, ..., 223) in response to requests, commands, or instructions from the processing device 118 to perform operations such as reading data, writing data, or erasing data in the memory (e.g., 221, ..., 223), and other such operations. The controller (e.g., 227) may include hardware, such as one or more integrated circuits and / or discrete components, buffer memory, or a combination thereof. The controller (e.g., 227) may be a microcontroller, dedicated logic circuitry (e.g., a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.), or another suitable processor. The controller (e.g., 227) may include one or more processors (processing devices) configured to execute instructions stored in local memory.

[0086] The local memory of a controller (e.g., 227) may include embedded memory configured to store instructions for performing various processing programs, operations, logic flows, and routines for controlling the operation of the memory subsystem (e.g., 205), including handling communications between the memory subsystem (e.g., 205) and the processing device 118, and other functions described in more detail below. The local memory of a controller (e.g., 227) may include read-only memory (ROM) for storing microcode and / or memory registers for storing, for example, memory pointers, fetched data, etc.

[0087] although Figure 2The example memory subsystem 205 in FIG has been described as including a controller 227, but in another embodiment of the present invention, a memory subsystem (e.g., 205) may not include a controller (e.g., 227) and may instead rely on external control (e.g., provided by a processor or controller separate from the memory subsystem (e.g., 205)).

[0088] In general, a controller (e.g., 227) may receive commands, requests, or instructions from processing device 118 according to a standard communication protocol for a communication channel (e.g., 203) and may convert the commands, requests, or instructions conforming to the standard protocol into detailed instructions or appropriate commands within the memory subsystem (e.g., 205) to achieve the desired access to the memories (e.g., 221, ..., 223). For example, a controller (e.g., 227) may be responsible for operations such as address conversion between logical addresses and physical addresses associated with memories (e.g., 221, ..., 223). The controller (e.g., 227) may further include host interface circuitry to communicate with processing device 118 via a physical host interface. The host interface circuitry may convert commands received from processing device 118 into command instructions to access memory devices (e.g., 221, ..., 223) and convert responses associated with the memory devices (e.g., 221, ..., 223) into information for processing device 118.

[0089] The memory subsystem (e.g., 205) may also include additional circuitry or components not illustrated. In some implementations, the memory subsystem (e.g., 205) may include a cache or buffer (e.g., DRAM) and address circuitry (e.g., row decoders and column decoders) that can receive addresses from a controller (e.g., 227) and decode the addresses to access memories (e.g., 221, ..., 223).

[0090] In one example, the memory bus 203 has one or more connectors to provide power to the memory subsystem (e.g., 205) and / or communicate with the memory subsystem (e.g., 205) via a predetermined protocol, and the memory subsystem (e.g., 205) has one or more connectors to receive power, data, and commands from the processing device 118. In one example, the processing device 118 can execute one or more operating systems to provide services, including memory access, in which synchronous memory access is used to access a portion of memory in the computer system (e.g., a page stored in NVRAM).

[0091] Figure 3An example computer system 300 is illustrated that stores metadata 320 used to access memory devices in a memory subsystem 302 according to some embodiments. The memory devices accessed in the memory subsystem 302 include DRAM 304, NVRAM 306, and NAND flash memory 308. In one embodiment, the computer system 300 alternatively and / or additionally stores the metadata 322 in the DRAM 304 used to access the memory devices.

[0092] In one embodiment, processing device 310 of computer system 300 accesses memory in an address space. In one example, the memory is main memory used by processing device 310 when executing one or more application programs. Processing device 310 accesses different memory devices using addresses in the address space.

[0093] In one embodiment, metadata 320, 322 associates a first address range of the address space with a memory device, such as DRAM 304, and associates a second address range of the address space with a different memory device, such as NVRAM 306 or NAND flash memory 308. In one example, the latency of DRAM 304 is less than the latency of NVRAM 306 and NAND flash memory 308.

[0094] The applications executing on processing device 310 include application 312, which is configured to include memory type 314. When application 312 is initially launched, application 312 provides memory type 314 to processing device 310 along with a request for an allocation of memory in main memory of computer system 300.

[0095] In response to a request for allocation of memory, processing device 310 queries metadata 320 and / or sends a query to metadata 322. Based on the results from one or both of these queries, processing device 310 allocates an address range in the address space to application 312.

[0096] In one embodiment, application 312 requests an indication of latency associated with a memory device from processing device 310. Processing device 310 accesses metadata 320, 322 to obtain a result and, based on this result, provides an indication of latency to application 312. In response to receiving the indication of latency, application 312 requests allocation of memory corresponding to a particular one of the memory devices (a memory device corresponding to memory type 314), or allocation of memory having performance characteristics that meet at least one or more predetermined thresholds and / or requirements.

[0097] In one embodiment, metadata 322 stores data that associates address ranges in the virtual address space with physical addresses in the memory devices of memory subsystem 302. In one example, metadata 322 stores address ranges 324 for NVRAM and address ranges 326 for NAND flash memory. In one example, address range 324 maps virtual or logical addresses of processing device 310 to physical addresses of NVRAM 306. In one example, address range 326 maps virtual or logical addresses of processing device 310 to physical addresses of NAND flash memory 308. In one embodiment, metadata 320 or 322 stores one or more address ranges that map addresses of processing device 310 for data stored in DRAM 304.

[0098] In one embodiment, metadata 322 is stored as part of a page table 328 that provides a mapping of virtual addresses to physical addresses for a memory management unit 316 of the computer system 300. The processing device 310 provides the virtual address to the memory management unit 316, which accesses the translation lookaside buffer 318 to obtain a physical address in one of the memory devices of the memory subsystem 302.

[0099] In one embodiment, translation lookaside buffer 318 is a cache that stores a portion of data from page table 328. In one example, buffer 318 stores a portion of metadata 322. In one embodiment, when a memory device in memory subsystem 302 is accessed, a portion of metadata 320 stored on computer system 300 is copied to translation lookaside buffer 318 for access by memory management unit 316.

[0100] In one embodiment, processing device 310 provides memory characteristics of different memory devices to application 312. Application 312 makes a request for an allocation of memory based on the provided memory characteristics.

[0101] In one embodiment, processing device 310 receives a requested latency from application 312. An address range is assigned to application 312 based on the requested latency.

[0102] In one embodiment, the processing device 310 determines a priority associated with the application 312. An address range is allocated to the application 312 based on the determined priority. In one example, a faster memory device type is selected for use with the determined priority. The processing device 310 uses metadata 320, 322 to select an address range for physically storing data in a memory device of the selected faster memory device type.

[0103] In one embodiment, the processing device 310 determines a change in priority of the application 312. In one example, the processing device 310 changes memory allocation for the application 312 in the address space based on the increase in priority of the application 312. In one example, in response to the increase in priority, the processing device 310 accesses metadata 320, 322 to determine an address range corresponding to a faster physical memory device.

[0104] In one embodiment, the processing device 310 prioritizes the application 312 based on observed characteristics associated with data accesses by the application 312 in the address space. The observed characteristics may be used to allocate memory usage to the application 312. In one embodiment, the processing device 310 determines one or more latencies associated with the physical memory devices. Metadata 320, 322 stores data regarding the determined one or more latencies, which may be used by the processing device 310 when initially allocating main memory and / or changing the allocation of main memory.

[0105] Figure 4 Memory module 401 is shown configured for memory bus access to volatile memory 402 and non-volatile memory 404 by a host computer system (not shown) according to some embodiments. Memory module 401 is an example of memory subsystem 302 or memory module 205. In one example, memory module 401 is a hybrid DIMM. Volatile memory 402 is, for example, DRAM.

[0106] Memory module 401 uses multiplexer 408 to provide memory controller 416 access to volatile memory 402 and non-volatile memory 404. Memory controller 416 is coupled to host interface 406 for the host system to handle read / write access. In one embodiment, multiplexer 408 is controlled based on a signal received from memory controller 416 in response to receiving a read or write command from the host system via host interface 406.

[0107] In one example, a host system accesses memory space (e.g., DRAM memory address space) on a memory module 401 (e.g., a DIMM). The DIMM exposes itself to the host as a DRAM channel. In one embodiment, a hypervisor in the host system controls data movement on the DIMM. For example, requests are made to move memory blocks into and out of the DRAM address space, exposing DRAM pages to software running on the host. The software is executed, for example, in a virtual machine (VM).

[0108] In one example, a page-in / page-out control path is provided for the driver to request a page that is currently in DRAM or in NVRAM. In one example, NVRAM has a much larger capacity than DRAM.

[0109] In one example, the memory module 401 is implemented as a DIMM. The non-volatile memory 404 is provided by a 3D XPoint memory package. In one example, pages of data obtained from the 3D XPoint memory are copied into and out of a buffer (page-in / page-out).

[0110] In one example, the host system can use normal DDR4 timing to read / write access to any DRAM or NVRAM address. For example, the host can generate any traffic according to DDR4 rules during those times.

[0111] In one example, the entire DDR address space of nonvolatile memory 404 is exposed to the host system. According to various embodiments, a controller of computer system 120 (eg, controller 116) can operate in the same manner as it accesses conventional DRAM (eg, same read / write and refresh timing cycles).

[0112] Figure 5 Host operating system 241 is shown accessing memory module 502 using memory bus access, according to at least some embodiments. Memory module 502 includes buffer 410. Buffer 410 is an example of buffer 121. In one example, buffer 410 stores at least a portion of metadata 322 and / or page table 328. Commands and data are received from host operating system 241 via host interface 406. In one example, host operating system 241 executes on computer system 120 or 300.

[0113] In one embodiment, the device driver 247 (eg, backend driver) is configured for memory access via the hypervisor 245. In one example, Figure 5 The system is implemented in Figures 1 to 3 in the computer system.

[0114] In one example, the host operating system 241 Figure 1 or 2 of the processing device 118 of the computer system or Figure 3 The host operating system 241 runs on the processing device 310. The host operating system 241 includes one or more device drivers (eg, 247) that provide memory services using the memory (eg, 221, ..., 223) of the memory subsystem (eg, memory module 205 or memory subsystem 302).

[0115] In one embodiment, the backend driver 247 maintains a mapping table 246. For example, the driver 247 maintains the mapping table 246 to include a mapping of pages of data stored in the DRAM 304, NVRAM 306, and NAND flash memory 308.

[0116] In one embodiment, the host operating system 241 includes a hypervisor 245 that deploys a virtual machine 249. The virtual machine 249 has a Figures 1 to 3 For example, the hypervisor 245 may use a portion of the memory (e.g., 221, ..., 223) of the memory subsystem (e.g., memory module 205) to provision virtual memory as part of the virtual machine 249.

[0117] Virtual machine 249 allows guest operating system 243 to provide resources and / or services to application programs (e.g., 251, ..., 253) running in guest operating system 243 in the same manner as operating system 243 running on a physical computing machine having the same or similar hardware set as that configured in the virtual machine. Hypervisor 245 manages the mapping between the virtual hardware configured in the virtual machine and the hardware services in the computing system managed by host operating system 241.

[0118] Device driver 248 (eg, front-end driver) communicates with back-end driver 247. Driver 247 and driver 248 can communicate for memory ballooning when extra DDR capacity (eg, capacity in DRAM or NVRAM) is available.

[0119] Figure 5 The hypervisor 245 is used to create a virtual machine 249. In general, the hypervisor 245 can create multiple virtual machines (e.g., 249) that can run the same guest operating system 243 or different guest operating systems. Different users and / or application sets can be assigned to use different virtual machines.

[0120] In some cases, the host operating system 241 is dedicated to providing services for the provisioning of virtual machines and does not run other applications. Alternatively, the host operating system 241 can provide additional services to support other applications, such as application programs (e.g., 251, ..., 253).

[0121] In one embodiment, the device driver 247 may be configured to request that a page be paged in from a slower memory (e.g., NVRAM) to a faster memory (e.g., DRAM) for use by the virtual machine 249. This request may be in response to a request from an application (e.g., Figure 3The processing device 310 moves the page from the slower memory to the faster memory based on the address range information stored as metadata 320, 322. In one example, the slower memory may be the non-volatile memory 404 in the memory module 401, and the faster memory may be the volatile memory 402 in the same memory module 401.

[0122] In one embodiment, the transfer of data (e.g., in response to a page-in request from the host operating system 241) occurs within the same memory subsystem (e.g., within the same memory module 401) to avoid or reduce congestion in a communication channel (e.g., the memory bus 203) connected to the processing device 118. For example, under the control of the controller 227 in the memory module 205, data may be copied from a slower memory 223 (e.g., NVRAM or NAND flash) in the memory module 205 to a faster memory 221 (e.g., DRAM) in the memory module 205 in response to one or more commands, requests, and / or instructions from the device driver 247.

[0123] In one embodiment, the hypervisor 245 not only requests the device driver 247 to access the memory (e.g., 221, ..., 223) in the memory subsystem (e.g., memory module 205), but also provides information that can be used to manage the pages in the memory (e.g., 221, ..., 223) to be used to the device driver 247. In one example, the provided information includes the stored metadata 320 or 322.

[0124] In one example, driver 247 is a memory mode driver used to access the memory address space in memory module 502 (e.g., DIMM). Driver 247 controls which pages are in the volatile memory of the DIMM at any one time. In one implementation, for example, the memory address space is exposed to guest operating system 243. In this hypervisor environment, guest operating system 243 sees the full storage capacity of the non-volatile memory (e.g., NVRAM and DRAM) in the DIMM.

[0125] In one example, only a few pages in the DDR DRAM are actively paged in via the host operating system 241. If a guest accesses a non-existent page, a page miss path in the host system's memory management unit (MMU) triggers a driver 247 to cause the page to be loaded (paged in). In one example, the page is loaded via a control register. Once the page is actually present in the DDR DRAM, the driver 247 can set up the MMU mapping (via mapping table 246) so that the guest application can directly read and write the data.

[0126] In one example, the client's front-end driver and the host's back-end driver communicate regarding access to the memory address space. In one example, when a page is determined to be stale (e.g., not frequently used based on a predetermined threshold), a request is made to push a portion of the data currently mapped in the DDR memory address space to the NVRAM memory (e.g., via an SRAM buffer) to make space in the DRAM memory available for other pages to be paged in. The back-end driver 247 communicates a page-out request to move data from the DDR DRAM to the NVRAM memory.

[0127] In one embodiment, backend driver 247 operates as a memory mode driver. Until driver 247 is loaded, there is no access to the NVRAM memory capacity of memory module 502. During this operation as a memory mode driver, guest operating system 243 treats the memory as normal, and driver 247 reserves DRAM pages on the memory module for page-in and page-out operations.

[0128] Driver 247 exposes NVRAM memory to guest operating system 243 and maintains page mappings, such as in mapping table 246. For example, driver 247 maintains a mapping between pages currently in DRAM and pages on NVRAM memory.

[0129] In one example, the driver 247 sets up a memory management unit mapping table at the host system to map any page currently stored in DRAM. If there is an access outside the mapped page to trigger a page-in request, a page-miss path from the client can be used. A page-out request can be made to maintain some memory space in DRAM.

[0130] In one embodiment, operation is not restricted to memory mode.The driver 247 can also operate as a block mode driver, for which the NVRAM memory is exposed as block mode storage.

[0131] In one embodiment, the memory module 502 maintains its own mapping table, which contains a list of pages in an SRAM buffer (not shown). This allows the host system to reduce latency in accessing those specific pages. The driver 247 ensures that the host does not access the page until its mapping is set and until the page-in request is completed.

[0132] In one embodiment, driver 247 implements a page-out operation. In one example, this operation is triggered as a thread. This operation swaps free pages out of DRAM memory and changes the mapping of valid pages.

[0133] Figure 6 A method is presented according to some embodiments for managing memory for a processing program in an address space of a computer system based on stored metadata that associates a virtual address range for the processing program in the address space with a physical address for a memory device in the computer system. For example, Figure 6 The method can be implemented in Figures 1 to 3 in the system.

[0134] Figure 6 The method may be performed by processing logic, which may include hardware (e.g., a processing device, circuitry, dedicated logic, programmable logic, microcode, hardware of a device, an integrated circuit, etc.), software (e.g., instructions running or executed on a processing device), or a combination thereof. In some embodiments, Figure 6 The method is at least partially performed by one or more processing devices (e.g. Figure 3 The processing device 310) is performed.

[0135] Although shown in a particular order or sequence, the order of the processes described may be modified unless otherwise specified. Therefore, the illustrated embodiments should be understood as examples only, and the illustrated processes may be performed in a different order, and some processes may be performed in parallel. Furthermore, one or more processes may be omitted in various embodiments. Therefore, not all processes are required in every embodiment. Other process flows are possible.

[0136] At block 601, an operating system maintains memory in an address space. Accessing memory includes accessing a first memory device and a second memory device using an address in the address space. In one example, the operating system Figure 3 306. In one example, the first memory device is DRAM 304 and the second memory device is NVRAM 306. In one example, the first memory device is NVRAM 306 and the second memory device is NAND flash memory 308.

[0137] At block 603, metadata is stored that associates a first address range of an address space with a first memory device. The metadata also associates a second address range of the address space with a second memory device. In one example, the stored metadata is Figure 3 The metadata 320 and / or 322 of FIG. In one example, the first address range is address range 324 and the second address range is address range 326.

[0138] At block 605, processing programs running in the computer system are managed based on the stored metadata. The processing programs include a first processing program and a second processing program. Data for the first processing program is stored in a first memory device, and data for the second processing program is stored in a second memory device. In one example, the data for the first processing program is stored in address range 324, and the data for the second processing program is stored in address range 326. In one example, the data for the first processing program is stored in an address range corresponding to the metadata 320, 322 stored in the physical memory in DRAM 304. In one example, the computer system is computer system 120 or 300.

[0139] In one embodiment, a method includes: Figure 3 The computer system includes a processing device 310 of the computer system accessing memory in an address space, wherein memory devices of the computer system are accessed by the processing device using addresses in the address space; storing metadata (e.g., metadata 320 and / or 322) that associates a first address range of the address space with a first memory device (e.g., DRAM 304) and a second address range of the address space with a second memory device (e.g., NVRAM 306), wherein a first latency of the first memory device is different from a second latency of the second memory device; and allocating the first address range to an application (e.g., application 312) executing on the computer system based on the stored metadata.

[0140] In one embodiment, allocating the first address range to the application is performed in response to a request from the application.

[0141] In one embodiment, the method further includes: providing an indication that the first delay is greater than the second delay in response to a first request from the application; receiving a second request made by the application based on the indication; and allocating the second address range to the application in response to receiving the second request.

[0142] In one embodiment, the first latency is less than the second latency, and the metadata is stored in the first memory device.

[0143] In one embodiment, the computer system uses a memory bus to access the first memory device and the second memory device, and wherein the metadata is stored in the second memory device.

[0144] In one embodiment, the metadata is stored in the first memory device, and the method further includes loading at least a portion of the metadata into a buffer (e.g., translation lookaside buffer 318), wherein the processing device queries the buffer to determine a physical address corresponding to a virtual address in the first address range.

[0145] In one embodiment, the computer system is a system-on-chip device and the buffer is a translation lookaside buffer.

[0146] In one embodiment, the method further comprises providing memory characteristics of the first and second memory devices to the application; wherein allocating the first address range to the application is in response to a request made by the application based on the provided memory characteristics.

[0147] In one embodiment, the method further comprises receiving a requested latency from the application, wherein allocating the first address range to the application is further based on the requested latency.

[0148] In one embodiment, the method further includes determining a priority level associated with the application, wherein allocating the first address range to the application is further based on the priority level.

[0149] In one embodiment, the first latency is less than the second latency; the second address range is allocated to the application before the first address range is allocated to the application; and the allocation of the first address range to the application is performed in response to determining an increase in the priority associated with the application.

[0150] In one embodiment, determining the increase in the priority level associated with the application is based on one or more observations regarding data access by the application in the address space.

[0151] In one embodiment, the method further comprises determining, by the processing device, a latency associated with the memory device, wherein storing the metadata further comprises storing the determined latency.

[0152] In one embodiment, a system includes: a first memory device; a second memory device; at least one processing device; and a memory containing instructions configured to instruct the at least one processing device to: access memory in an address space maintained by an operating system, the access including accessing the first memory device and the second memory device using addresses in the address space; store metadata associating a first address range of the address space with the first memory device and a second address range of the address space with the second memory device; and manage, by the operating system, handlers including a first handler and a second handler based on the stored metadata, wherein data for the first handler is stored in the first memory device and data for the second handler is stored in the second memory device.

[0153] In one embodiment, the first processing program has a first priority, the second processing program has a second priority, and the first memory device is selected to store the data for the first processing program in response to determining that the first priority is higher than the second priority.

[0154] In one embodiment, the first processing program corresponds to a first application; the instructions are further configured to instruct the at least one processing device to receive a request from the first application indicating a type of memory to be used to store data; and select the first memory device to store the data for the first processing program based on the indicated type of memory.

[0155] In one embodiment, the system further includes a buffer to store the metadata, wherein the operating system receives a virtual address in the first address range from the first handler and accesses the buffer to determine a physical address of the first memory device corresponding to the virtual address.

[0156] In one embodiment, a read latency of the first memory device is less than a read latency of the second memory device, and the instructions are further configured to instruct the at least one processing device to store the metadata in the first memory device.

[0157] In one embodiment, the system further includes a memory management unit (eg, memory management unit 316) configured to map virtual addresses in the first address range to physical addresses in the first memory device when accessing stored data for the first handler.

[0158] In one embodiment, a non-transitory machine-readable storage medium stores instructions that, when executed on at least one processing device, cause the at least one processing device to at least: access memory in an address space, wherein addresses in the address space are used by the at least one processing device to access a memory device of a computer system; store metadata associating a first address range of the address space with a first memory device and a second address range of the address space with a second memory device; provide first data to an application executing on the computer system, the first data indicating that a first latency of the first memory device is less than a second latency of the second memory device; in response to providing the first data to the application, receive a request from the application to store second data associated with the application in the first memory device; in response to the application's request to store the second data, query the stored metadata to provide a result; and store the second data in the first memory device based on the result.

[0159] Figure 7 is a block diagram of an example computer system on which embodiments of the present invention may operate. Figure 7 An example machine illustrating a computer system 600 in which a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein may be executed. In some embodiments, the computer system 600 may correspond to a host system (e.g., Figure 1 120), the host system including, coupled to, or utilizing a memory subsystem (e.g., Figure 1 10) or can be used to perform operations of the metadata component 113 (e.g., execute instructions to perform operations corresponding to the reference Figures 1 to 6 In some embodiments, the machine may be connected (e.g., via a network) to other machines in a LAN, an intranet, an extranet, and / or the Internet. The machine may operate in the capacity of a server or a client machine in a client-server network environment, as a peer machine in a peer-to-peer (or distributed) network environment, or as a server or a client machine in a cloud computing infrastructure or environment.

[0160] The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular phone, a network appliance, a server, a network router, a switch or bridge, an Internet of Things (IoT) device, or any machine capable of executing a set of instructions (sequentially or otherwise) that specify actions to be taken by the machine. Further, while a single machine is described, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

[0161] The example computer system 600 includes a processing device 602, a main memory 604 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) (e.g., synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM)), static random access memory (SRAM), etc.), and a data storage system 618, which communicate with each other via a bus 630 (which may include multiple buses).

[0162] Processing device 602 represents one or more general-purpose processing devices, such as a microprocessor, a central processing unit, or the like. More specifically, the processing device may be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, or a processor that implements other instruction sets, or a processor that implements a combination of instruction sets. Processing device 602 may also be one or more special-purpose processing devices, such as an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a digital signal processor (DSP), a network processor, or the like. Processing device 602 is configured to execute instructions 626 for performing the operations and steps discussed herein. Computer system 600 may further include a network interface device 608 for communicating via a network 620.

[0163] The data storage system 618 may include a machine-readable storage medium 624 (also referred to as a computer-readable medium) having stored thereon one or more sets of instructions 626 or software embodying any one or more of the methodologies or functions described herein. During execution thereof by the computer system 600, the instructions 626 may also reside, completely or at least partially, within the main memory 604 and / or within the processing device 602, the main memory 604 and the processing device 602 also constituting machine-readable storage media. The machine-readable storage medium 624, the data storage system 618, and / or the main memory 604 may correspond to Figure 1 Memory subsystem 110.

[0164] In one embodiment, the instructions 626 include implementing instructions corresponding to the metadata component 113 (e.g., reference Figures 1 to 6 Although the machine-readable storage medium 624 is shown as a single medium in the example embodiment, the term "machine-readable storage medium" should be taken to include a single medium or multiple media storing one or more sets of instructions.

[0165] Page tables associated with memory types

[0166] Various embodiments related to page table entries that map virtual addresses of virtual pages to physical addresses in memory devices of different memory types are now described below. The generality of the following description is not limited by the various embodiments described above.

[0167] In previous memory management units (MMUs) of computer systems that use different types of physical memory devices for data storage, there was a technical problem: the MMU was unaware of how to physically map memory for various virtual pages to different types of memory devices (e.g., whether to map a virtual page to a physical address in DRAM, NVRAM, or flash memory). For example, the MMU did not store data regarding how each virtual page was mapped to a different type of memory device. Furthermore, memory type agnosticism is only one limitation. Even in a homogeneous memory system (e.g., a NUMA architecture), different physical addresses may have different access characteristics (of which the MMU is unaware).

[0168] In one example, if a virtual page for a processing program is mapped to a physical memory device (e.g., flash memory) significantly more slowly than other memory devices (e.g., DRAM), the processing program may be forced to run slowly due to the inability to quickly access data. For example, the processing program may need a virtual page from main memory in order to continue processing. If the required virtual page is actually stored in a slow physical memory device, the processing program may be significantly delayed while waiting to access the virtual page.

[0169] Various embodiments described below provide technical solutions to one or more of the above technical problems. In one embodiment, a method includes: associating a virtual page with a first memory type by at least one processing device (e.g., a CPU and / or MMU); generating a page table entry to map the virtual address of the virtual page to a physical address in a first memory device of the first memory type; and using the page table entry to store the virtual page at the physical address in the first memory device. In one example, the page table entry is copied to a cache of a memory management unit and / or a microprocessor. In one example, the page table entry is copied to a translation lookaside buffer (TLB) used by the memory management unit when storing the virtual page in the main memory of a central processing unit.

[0170] In one embodiment, the mobile device's operating system manages the location of virtual pages associated with memory types. For example, a memory type can be DRAM, NVRAM, or NAND flash memory. When a virtual page is associated with a specific memory type, the operating system generates a page table entry to map the virtual page's logical address to the corresponding memory type. The processor can request that a memory page be transferred to a different type of memory by changing its memory type.

[0171] In one example, an application or other software executing on a computing device has provided information to an operating system identifying the type of memory the application or other software requires for processing. In response, the operating system associates one or more virtual pages of the application or software with a physical memory device corresponding to the identified memory type requested by the application or software. For example, in response to a request for NVRAM memory type made by the application, a virtual page is allocated to the application. The physical address corresponding to the allocated virtual page is used to store data in an NVRAM device (e.g., a cross-point memory device).

[0172] Figure 8 An example computer system 800 is illustrated that uses one or more page tables 804, 806 to access memory devices on a memory bus 812 in accordance with some embodiments. The memory devices may include DRAM 304, NVRAM 306, and NAND flash memory 308 of the memory subsystem 802.

[0173] Computer system 800 is Figure 3 The memory subsystem 802 is an example of a computer system 300. Figure 3 302. The memory bus 812 is Figure 2 An example of a memory bus 203.

[0174] Operating system 808 runs on processing device 310. Operating system 808 allocates main memory of processing device 310 to various applications. These applications include application 312, which has memory type 314. In one example, memory type 314 is embedded in the code of application 312. In one example, memory type 314 is provided to processing device 310 by a different computing device (not shown). In one example, the different computing device is a server that provides memory type 314 associated with a request for memory allocation made by application 312.

[0175] Operating system 808 manages the memory of computer system 800 using memory management unit (MMU) 316. In one embodiment, virtual pages associated with applications, including application 312, are mapped to physical memory residing in memory subsystem 802. MMU 316 accesses page table entries to determine the physical address in memory that corresponds to the virtual page that the application needs to access.

[0176] Page table entries may be stored in page table 804 and / or page table 806. In one example, MMU 316 queries page tables 804, 806 by providing a virtual address corresponding to a virtual page. The result from the query is a physical address of a memory device (eg, DRAM 304).

[0177] In one embodiment, page table 804 is stored in DRAM 304. In one embodiment, page table 806 is stored in memory of computer system 800. In one example, when a page table entry does not exist in computer system 800, MMU 316 accesses page table 804. In one example, the page table entry is split between page table 804 and page table 806. In one example, the page table entry in page table 806 corresponds to a handler with a higher priority. In one example, processing device 310 assigns a priority to a handler corresponding to an application based on the memory type corresponding to the application received by processing device 310.

[0178] In one embodiment, the MMU 316 uses both the page table 804 and the metadata 322 for memory management. In one example, the MMU 316 uses the metadata 322 to select a memory device for storing data corresponding to a virtual page. The selected memory device may correspond to the requested memory type (e.g., the memory type 314). In another embodiment, the MMU 316 uses both the page table 806 and the metadata 320 for memory management.

[0179] In one embodiment, some of the page table entries from the page tables 804, 806 are copied to a translation lookaside buffer (TLB) 810. When mapping a virtual address to a physical address, the MMU 316 first checks the TLB 810 for the page table entry corresponding to the virtual address. The page table entry in the TLB 810 may also contain data copied from the metadata 320, 322.

[0180] In one embodiment, an application 312 requests an allocation of memory by the processing device 310. In response, the operating system 808 uses the MMU 316 to generate a page table entry that maps the virtual address of the virtual page of the application 312 to a physical address in the memory device. The memory device is selected to have a memory type 314. In one embodiment, the memory device is selected using metadata 322. In one embodiment, after the page table entry is generated, a copy of the page table entry is stored in the TLB 810 and / or the metadata 320, 322 is updated.

[0181] In one embodiment, processing device 310 determines a change associated with application 312. In one example, the change is a change in the priority of one or more functions performed by application 312. In one example, the change is a change in the context associated with application 312 (e.g., a security context, etc.).

[0182] In response to determining the change, operating system 808 associates one or more virtual pages of application 312 with the new memory type. For example, the memory type of application 312 may be changed from NVRAM to DRAM in response to determining that application 312 has a higher priority. In response to the change to the new memory type, page table entries are updated to map the virtual addresses of the virtual pages to physical addresses in the new memory device of the new memory type. MMU 316 then uses the updated page table entries to transfer the virtual pages from the currently used memory device to the new memory device.

[0183] In one embodiment, computer system 800 and / or processing device 310 is a system on chip (SoC). In one example, a SoC may be or include an integrated circuit or chip that integrates any two or more components of a computing device. The two or more components may include at least one or more of a central processing unit (CPU), a graphics processing unit (GPU), memory, input / output ports, and auxiliary storage. For example, a SoC may include a CPU, a GPU, graphics and memory interfaces, a hard disk, a USB connector, random access memory, read-only memory, auxiliary storage, or any combination thereof on a single circuit die. Furthermore, where the processor chip is a SoC, the SoC may include at least a CPU and / or a GPU.

[0184] In one example of a SoC, two or more components may be embedded on a single substrate or microchip (chip). Generally speaking, a SoC differs from a conventional motherboard-based architecture in that an SoC integrates all of its components into a single integrated circuit; whereas a motherboard houses and connects removable or replaceable components. Because two or more components are integrated on a single substrate or chip, an SoC consumes less power and occupies a much smaller area than a multi-chip design with equivalent functionality. In some embodiments, the memory system or subsystem described herein may be connected to or part of an SoC in a mobile computing device (e.g., a smartphone), an embedded system, and an Internet of Things (IoT) device. In one embodiment, the memory subsystem 802 may be or be included in the SoC. Furthermore, if the memory subsystem 802 is a SoC, the SoC may include at least a data processing unit.

[0185] Figure 9An example page table 900 is illustrated having page table entries 902 and 904 according to some embodiments. Each page table entry 902 and 904 includes a virtual address, a corresponding physical address, and a memory type. In one example, the memory type is memory type 314. In one example, memory type 314 is used to update the page table entry in response to a new allocation or change in allocation of main memory for a handler. In various embodiments, each entry 902 and 904 may further include a handler identifier, usage data, and / or a memory device identifier. Page table 900 is an example of page table 804 or 806.

[0186] In one embodiment, for each page table entry, the virtual address corresponds to a virtual page of an application, such as application 312. The physical address corresponds to a location in a memory device of memory subsystem 802. The memory type corresponds to the type of memory device at the physical address.

[0187] In one embodiment, the handler identifier of each page table entry is used to identify the handler executing on the processing device 310 that is using the virtual page at the virtual address. For example, the handler identifier is a unique identifier for each handler running in the computer system 800.

[0188] In one embodiment, the usage data for each page table entry may correspond to data regarding accesses or other usage associated with data in the virtual page stored at the virtual address of the page table entry. In one example, the usage data relates to a usage pattern of the virtual page. In one example, the usage pattern is the frequency of accesses to the data in the virtual page. In one example, the frequency of accesses may be the frequency of read and / or write accesses. In one example, the usage data relates to the last time the data in the virtual page was used.

[0189] In one embodiment, each page table entry may include a memory device identifier. In one example, the memory device identifier uniquely identifies the physical memory device storing the data corresponding to the virtual address. In one example, the memory device identifier uniquely corresponds to DRAM 304 or NVRAM 306.

[0190] In one embodiment, each page table entry may further include at least a portion of metadata 320 and / or 322. In one example, the included metadata may be an address range of a physical memory device.

[0191] Figure 10 Methods for generating page table entries to map virtual addresses of virtual pages to physical addresses in memory devices of different memory types are presented according to some embodiments. For example, Figure 10 The method can be implemented in Figure 8 system or Figure 7In the computer system 600.

[0192] Figure 10 The method may be performed by processing logic, which may include hardware (e.g., a processing device, circuitry, dedicated logic, programmable logic, microcode, hardware of a device, an integrated circuit, etc.), software (e.g., instructions running or executed on a processing device), or a combination thereof. In some embodiments, Figure 10 The method is at least partially performed by one or more processing devices (e.g. Figure 8 The processing device 310) is performed.

[0193] Although shown in a particular order or sequence, the order of the processes described may be modified unless otherwise specified. Therefore, the illustrated embodiments should be understood as examples only, and the illustrated processes may be performed in a different order, and some processes may be performed in parallel. Furthermore, one or more processes may be omitted in various embodiments. Therefore, not all processes are required in every embodiment. Other process flows are possible.

[0194] At block 1001, a virtual page is associated with a first memory type. In one example, the first memory type is DRAM, NVRAM, or flash memory. In one example, the virtual page corresponds to an application 312. In one example, the virtual page corresponds to memory allocated to the application 312 in response to a request for allocation of main memory for use by the processing device 310.

[0195] At block 1003, a page table entry is generated. The page table entry maps a virtual address of a virtual page to a physical address in a memory device of the first memory type. In one example, the page table entry resides in page table 804 or 806. In one example, the memory device is DRAM 304, NVRAM 306, or NAND flash memory 308.

[0196] At block 1005 , the virtual page is stored at the physical address in the memory device using the page table entry. In one example, the memory management unit 316 uses the page table entry cached in the translation lookaside buffer 810 to store the virtual page.

[0197] In one embodiment, a method includes associating, by at least one processing device (e.g., processing device 310 and / or memory management unit 316), a virtual page with a first memory type; generating a page table entry (e.g., page table entry 902) to map a virtual address of the virtual page to a physical address in a first memory device (e.g., DRAM 304) of the first memory type; and storing the virtual page at the physical address in the first memory device using the page table entry.

[0198] In one embodiment, the method further includes associating, by at least one processing device, the virtual page with a second memory type; updating the page table entry to map the virtual address of the virtual page to a physical address in a second memory device (e.g., NVRAM 306) of the second memory type; and transferring the virtual page from the first memory device to the second memory device using the updated page table entry.

[0199] In one embodiment, an operating system (eg, operating system 808) is running on the at least one processing device, and generating the page table entry is performed by the operating system in response to associating the virtual page with the first memory type.

[0200] In one embodiment, associating the virtual page with the first memory type is performed in response to a request received by an operating system from an application (eg, application 312).

[0201] In one embodiment, the request from the application is provided to the first memory type (eg, memory type 314).

[0202] In one embodiment, the method further includes managing, by an operating system of a computing device, a physical location of virtual pages stored in a memory device, wherein the memory device includes the first memory device and a second memory device of a second memory type, and wherein a latency of the first memory device is less than a latency of the second memory device.

[0203] In one embodiment, differences other than and / or in addition to latency may exist between a first memory device and a second memory device. In one example, the power and / or performance characteristics of the first memory device differ from those of the second memory device, which has lower-power memory and / or longer-lasting memory. Examples of differences in memory characteristics between different memory devices or types or memories may include performance, power, durability, error rates, and / or combinations thereof. In some cases, for example, these differences may exist between devices of the same memory type (e.g., error rates may vary for different chips of the same memory type used to store process data).

[0204] In one embodiment, the first memory type is dynamic random access memory, and the second memory type is non-volatile random access memory or flash memory.

[0205] In one embodiment, the method further includes: monitoring, by an operating system, an application running on the at least one processing device; and updating, based on the monitoring, the page table entry to map the virtual address of the virtual page to a physical address in a second memory device of a second memory type.

[0206] In one embodiment, the method further includes: determining a context of operation associated with the at least one processing device; selecting a second memory type based on the determined context; and in response to selecting the second memory type, updating the page table entry to map the virtual address of the virtual page to a physical address in a second memory device of the second memory type.

[0207] In one embodiment, the method further includes: associating, by the at least one processing device, the virtual page with a second memory type; updating mapping data in a translation lookaside buffer (e.g., TLB 810) in response to associating the virtual page with the second memory type; and transferring, by a memory management unit, the virtual page from the first memory device to the second memory device based on accessing the updated mapping data in the translation lookaside buffer.

[0208] In one embodiment, handlers are executing on the at least one processing device, and the page table entry includes a handler identifier of a first handler using the virtual page.

[0209] In one embodiment, the page table entry includes data regarding usage patterns of one or more applications running on the at least one processing device.

[0210] In one embodiment, the data regarding the usage pattern is at least one of a usage frequency or a last usage time.

[0211] In one embodiment, a system includes: a first memory device; a page table storing page table entries that map virtual addresses to physical addresses in memory devices of different memory types, the memory devices including the first memory device; at least one processing device; and a memory containing instructions configured to instruct the at least one processing device to: determine an association of a virtual page with a first memory type; determine that the first memory device corresponds to the first memory type; and generate a page table entry to map a virtual address of the virtual page to a first physical address of the first memory device.

[0212] In one embodiment, said at least one processing device uses a main memory having data stored on said memory device, and wherein determining said association of said virtual page with said first memory type is performed in response to a request for allocation of said main memory by an application.

[0213] In one embodiment, the instructions are further configured to instruct the at least one processing device to: store metadata (e.g., metadata 320, 322) associating address ranges in main memory with physical addresses in the memory device; wherein determining that the first memory device corresponds to the first memory type is based on the stored metadata.

[0214] In one embodiment, the instructions are further configured to instruct the at least one processing device to store the virtual page at the first physical address in the first memory device using the page table entry.

[0215] In one embodiment, the system further includes a memory management unit (e.g., memory management unit 316) and a translation lookaside buffer, wherein the instructions are further configured to instruct the at least one processing device to: update mapping data in the translation lookaside buffer based on a change in a memory type associated with the virtual page from the first memory type to a second memory type; and transfer, by the memory management unit, the virtual page from the first memory device to a second memory device of the second memory type based on the updated mapping data.

[0216] In one embodiment, the changing of memory type is performed in response to a request made by an application executing on the at least one processing device, or in response to a determination made by the at least one processing device that a priority of a processing program or application has changed.

[0217] In one embodiment, a non-transitory machine-readable storage medium stores instructions that, when executed on at least one processing device, cause the at least one processing device to at least: associate a virtual page with a first memory type; generate a page table entry to map a virtual address of the virtual page to a physical address in a first memory device of the first memory type; and store the virtual page at the physical address in the first memory device using the page table entry.

[0218] Binding data to a namespace

[0219] Various embodiments related to binding data to a namespace in a memory system having physical memories of different memory types are now described below.The generality of the following description is not limited by the various embodiments described above.

[0220] In previous memory systems, the operating system made main memory accessible to applications, and main memory was allocated from a single logical address space (e.g., from virtual addresses in the address space). Specifically, the operating system did not make any mapping controls accessible to applications, and therefore the applications had no control over which type of memory was used to store data. Instead, the operating system and / or the processor controlled the mapping via page tables and translation lookaside buffers. The page table defined the mapping between pages of logical addresses and pages of physical memory cells in the computer system's memory devices. The total size of the page table was relatively large. Therefore, most of the page table was stored in memory (e.g., DRAM for main memory). A portion of the data from the page table that was currently being used to look up a physical memory address was cached in the processor / memory controller's translation lookaside buffer.

[0221] The aforementioned situation with previous memory systems creates a technical problem where certain data cannot be accessed promptly by applications due to the significant latency of the actual physical memory devices storing the data. Consequently, application execution can be delayed for extended periods. In some cases, this latency can lead to system failures that require timely responses or other actions. For example, real-time control systems can fail due to slow data access from main memory. In one example, autonomous vehicle navigation control can fail due to excessive latency in the portion of main memory storing critical data.

[0222] The inability of applications to control the mapping of main memory usage to certain physical memory devices also prevents applications from selecting memory with higher reliability, which creates a technical problem in which critical data may be lost due to functional failures of the memory (e.g., failures in accessing data from physical memory devices with higher failure rates).

[0223] The various embodiments described below provide technical solutions to one or more of the above technical problems. In one embodiment, an application manages the mapping of data to a physical memory device used by an operating system for random memory access by specifying the memory type to be stored. The application uses the operating system to allocate a portion of memory (e.g., based on a request made by the application to the operating system) and uses memory units of the specified memory type based on the memory addresses of the memory units. In one example, the operating system informs the application of the virtual memory address range corresponding to the specified memory type.

[0224] In one embodiment, data is accessed by an operating system via a namespace table managed by the operating system. In one embodiment, the namespace table assigns names to memory addresses in main memory. In one embodiment, names are assigned to a range of virtual addresses in the address space of main memory used by applications. In one embodiment, namespaces are identified by namespace identifiers (e.g., using arbitrary identifiers Namespace A, Namespace B, and Namespace C, where each identifier is associated with a different type of memory).

[0225] In one embodiment, namespaces are used for memory access. Each namespace is a named logical reference to a set of memory cells in which memory addresses are defined. Applications allocate memory from namespaces. The operating system provides services that can be called by applications to bind and / or rebind namespaces to specific types of memory (e.g., DRAM, NVRAM, NAND flash). When a namespace is bound to a type of memory, the operating system adjusts one or more page tables to map logical memory addresses in the namespace to physical memory cells of the specific memory type in the computer system. When accessing memory cells via logical addresses in the namespace, data from the one or more page tables is loaded and cached in a translation lookaside buffer of the processor / memory controller for conversion to physical memory addresses.

[0226] In one embodiment, namespaces are created in different types of memory devices (e.g., DRAM, NVRAM, and NAND flash). Applications can dynamically change the binding between a dataset and a namespace to move the data to the desired memory device. In one embodiment, the operating system detects the change in binding and causes the data to be moved. In one embodiment, the operating system causes the memory management unit to update the page table, causing the data to be moved from the currently used memory device to the desired memory device.

[0227] In one embodiment, data stored for random access as main memory is organized by various virtual address ranges. A set of virtual address ranges can be associated with a namespace identifier.

[0228] In one embodiment, the kernel of an operating system controls all hardware devices in a computer system with the assistance of firmware and device drivers. The kernel manages memory access to programs in random access memory (RAM) and determines which programs get access to certain hardware resources.

[0229] An operating system provides an interface between application programs and the computer system's hardware. Application programs interact with the hardware based on programs managed by the operating system. The operating system also provides services to applications. When an application executes, the operating system's kernel creates a handler. The kernel allocates memory space and a priority for the handler, loads the program binary code into memory, and initiates the application's execution.

[0230] In one embodiment, the kernel allocates memory space based at least in part on namespace data provided by the application. In one example, the application provides a namespace corresponding to a memory type. In response, the kernel allocates memory space in a physical memory device corresponding to the memory type. In one example, the kernel uses virtual memory addressing (e.g., paging or segmentation) to determine the memory each program can access at any given time.

[0231] Figure 11 An example computer system is illustrated that uses a namespace table 1104 to map namespaces to different memory types of physical memory in the computer system according to some embodiments. Physical memory is used to provide random access memory that can be accessed by the computer system 1100 via the memory bus 812. The memory subsystem 1102 provides physical memory used as random access memory and is accessed by the processing device 310 using the memory management unit 316. In one example, the computer system 1100 and the memory subsystem 1102 are on the same integrated circuit (IC) chip or on different IC chips. In one example, the computer system 1100 and the memory subsystem 1102 are each part of the same system on a chip (SoC).

[0232] Computer system 1100 is Figure 8 The memory subsystem 1102 is an example of a computer system 800. Figure 8 An example of a memory subsystem 802.

[0233] Physical storage is provided by memory devices of different memory types, including DRAM 304, NVRAM 306, and NAND flash memory 308. In other embodiments, various other types of memory and / or other combinations of memory types may be used.

[0234] Each memory device corresponds to a namespace identifier. For example, DRAM 304 corresponds to the identifier "namespace A." NVRAM 306 corresponds to the identifier "namespace B." NAND flash memory 308 corresponds to the identifier "namespace C."

[0235] In one embodiment, each memory device can store various data associated with its assigned namespace. Figure 11 In one example, the namespace data includes a namespace identifier. In one example, the namespace data includes a physical address range corresponding to DRAM 304. In one example, the namespace data includes a portion of data from metadata 320, 322. In one example, the namespace data includes a portion of data from page table 804.

[0236] In one embodiment, namespace table 1104 is stored in the memory of computer system 1100. Namespace table 1104 provides a mapping between namespace identifiers and memory types. For example, namespace identifier "namespace A" is mapped to a memory type of DRAM.

[0237] In one embodiment, when an application 312 requests an allocation of random access memory from the processing device 310, the operating system 808 creates a namespace identifier and associates a memory type with the namespace identifier. The namespace table 1104 is updated to store this association. In one example, the memory type is the memory type 314 as provided by the application 312. In one example, the operating system 808 determines the memory type based on characteristics associated with the application 312. In one example, the operating system 808 determines the memory type based on the priority of the application 312.

[0238] In one embodiment, application 312 provides a request to operating system 808 associated with memory management. The request includes a namespace identifier associated with or related to the identified data. In response to receiving the request, operating system 808 accesses namespace table 1104 to perform one or more various actions or operations associated with the identified data. In one example, operating system 808 moves the identified data from an existing memory device of one memory type to a new memory device of another memory type corresponding to the received namespace identifier. In one example, operating system 808 performs one or more operations on the identified data and stores the results of the operations in the memory type associated with the namespace provided with the request. In one example, operating system 808 provides confirmation of the completion of the action to application 312.

[0239] In one embodiment, memory is allocated for use by application 312. Memory is allocated from a namespace. In one example, the namespace already exists in namespace table 1104. In another example, the namespace is created in response to a request for memory allocation. The created namespace is stored in namespace table 1104.

[0240] Bind an existing or newly created namespace to a memory type. In response to binding a namespace to a memory type, adjust one or more page tables to map logical memory addresses and namespaces to memory devices of the memory type. In one example, page table 806 and / or page table 804 are updated in response to binding a namespace to a memory type.

[0241] In one embodiment, the operating system 808 creates a namespace for a memory device and binds data to the namespace. In one example, the data is identified by a virtual address range. In response to binding the data to the namespace, the data is stored in the memory device associated with the created namespace. In one example, binding the data to the namespace includes mapping virtual addresses of the storage namespace to physical addresses of the memory device.

[0242] In one embodiment, one or more virtual addresses of the namespace correspond to virtual pages of a handler managed by operating system 808 using page table 804. In one example, page table 804 includes page table entries that map virtual addresses of the namespace to physical addresses of a memory device.

[0243] Figure 12 An example namespace table 1200 is illustrated having records 1202, 1204, 1206 that map namespaces to different types of memory in a computer system, according to some embodiments. In one example, the computer system is computer system 1100. Namespace table 1200 is an example of namespace table 1104.

[0244] Each record includes a namespace identifier (eg, namespace A) associated with a memory type (eg, DRAM or NVRAM). In one example, a change in the memory type of record 1202 causes page table 900 to be updated so that page table entry 902 has a matching memory type.

[0245] Each record may further include a virtual address, a physical address, and / or a data identifier. In one example, a virtual address may be a range of virtual addresses corresponding to the memory type of the record. In one example, a physical address may be a range of physical addresses of one or more memory devices corresponding to the memory type of the record.

[0246] In one example, the data identifier identifies data associated with the namespace identifier. In one example, the data identifier is an address range in the address space of the processing device 310. In one example, the data identifier is a physical address range of data stored in one or more memory devices of the recorded memory type.

[0247] In one embodiment, a portion of data from the stored metadata 320, 322 is copied to a record in the namespace table 1200. In one example, the portion of data is copied in response to a change in the memory type associated with the namespace identifier of the record. In one example, the portion of data is copied in response to a change in the virtual address, physical address, and / or data identifier associated with the record.

[0248] Figure 13 Methods for binding data to namespaces in a memory system having physical memories of different memory types are presented according to some embodiments. For example, Figure 13 The method can be implemented in Figure 11 in the system.

[0249] Figure 13 The method may be performed by processing logic, which may include hardware (e.g., a processing device, circuitry, dedicated logic, programmable logic, microcode, hardware of a device, an integrated circuit, etc.), software (e.g., instructions running or executed on a processing device), or a combination thereof. In some embodiments, Figure 13 The method is at least partially performed by one or more processing devices (e.g. Figure 11 The processing device 310) is performed.

[0250] Although shown in a particular order or sequence, the order of the processes described may be modified unless otherwise specified. Therefore, the illustrated embodiments should be understood as examples only, and the illustrated processes may be performed in a different order, and some processes may be performed in parallel. Furthermore, one or more processes may be omitted in various embodiments. Therefore, not all processes are required in every embodiment. Other process flows are possible.

[0251] At block 1301, memory is allocated from a namespace for use by an application. The namespace is a logical reference to one or more physical memory devices in which physical addresses are defined. In one example, the physical addresses are defined by the operating system 808. In one example, the application is application 312.

[0252] At block 1303, a namespace is bound to a memory type. In one example, the namespace is bound to the memory type 314. In one example, the namespace-to-memory type binding is stored in the namespace table 1104.

[0253] At block 1305, in response to binding the namespace to a memory type, page tables are adjusted to map logical memory addresses in the namespace to memory devices of the memory type. In one example, page table 804 and / or page table 806 are adjusted. In one example, the logical memory addresses are virtual addresses of virtual pages of application 312. In one example, the memory device is DRAM 304.

[0254] In one embodiment, a method includes: creating, by at least one processing device (e.g., processing device 310 and / or memory management unit 316), namespaces for memory devices of different memory types (e.g., DRAM 304, NVRAM 306, and NAND flash memory 308), the namespaces including a first namespace (e.g., "namespace A") for a first memory device of a first memory type, and a second namespace (e.g., "namespace B") for a second memory device of a second memory type; binding data to the first namespace (e.g., storing the binding in namespace table 1104); and storing the data in the first memory device in response to binding the data to the first namespace.

[0255] In one embodiment, storing the data in the first memory device includes moving the data from the second memory device to the first memory device.

[0256] In one embodiment, binding the data to the first namespace includes changing a binding of the data from the second namespace to the first namespace.

[0257] In one embodiment, an operating system (eg, operating system 808) runs on the at least one processing device, and binding the data to the first namespace is performed by the operating system in response to a request made by an application (eg, application 312).

[0258] In one embodiment, the first namespace is created by the operating system in response to a request made by the application.

[0259] In one embodiment, creating the namespaces includes associating a corresponding virtual address (eg, a virtual address in the page tables 804 , 806 ; a virtual address in the metadata 320 , 322 ) with each namespace.

[0260] In one embodiment, binding the data to the first namespace includes storing a mapping between a virtual address of the first namespace (e.g., a virtual address in page tables 804, 806; a virtual address in metadata 320, 322) and a first physical address of the first memory device.

[0261] In one embodiment, the virtual addresses of the first namespace are in a first address range of an address space of the at least one processing device, and wherein storing the mapping comprises storing metadata (e.g., metadata 320, 322) associating the first address range with the first memory device.

[0262] In one embodiment, the virtual address of the first namespace corresponds to a virtual page of a handler managed by an operating system using a page table (e.g., page tables 804, 806), and wherein storing the mapping includes generating a page table entry in the page table mapping the virtual address of the first namespace to the first physical address.

[0263] In one embodiment, the method further includes storing, by the operating system, in memory an association between the namespace and the data set bound to the namespace (eg, a binding for a record in the namespace table 1104 ).

[0264] In one embodiment, the method further includes: determining an increase in priority of an application executing on the at least one processing device; wherein binding the data to the first namespace is performed in response to determining the increase in priority, wherein binding the data to the first namespace includes a change in binding from the second namespace to the first namespace, and wherein a latency of the first memory device (e.g., DRAM 304) is less than a latency of the second memory device (e.g., NVRAM 306 or NAND flash memory 308).

[0265] In one embodiment, if a processing program is determined to be significantly write-intensive (e.g., exceeding a predetermined number and / or frequency of writes), the system may bind data to a namespace backed by, for example, more persistent memory, rather than determining an increase in priority for binding data to a first namespace (where the latency of the first memory device is lower). In another example, if a processing program is determined to be mission-critical, the system may bind data to a namespace backed by more resilient memory (or if a processing program is determined to be less important or insignificant, the system may bind data to a namespace backed by less resilient memory).

[0266] In one embodiment, a handler may be determined to have one or more specific characteristics (e.g., priority, consequence, interactivity, bandwidth / power consumption, etc.) Based on this determination, data associated with the handler is bound to a namespace backed by memory having complementary characteristics that correspond to and / or are more preferably suited to the determined one or more characteristics.

[0267] In one embodiment, creating the first namespace includes storing an identification of the first namespace in a memory of the first memory device (e.g., storing a namespace identifier and / or another identification as Figure 11 The "Namespace A Data" section).

[0268] In one embodiment, the method further includes receiving a request for allocation of memory from an application, wherein the request specifies that data be stored in physical memory of the first memory type (eg, DRAM).

[0269] In one embodiment, a system includes: a first memory device of a first memory type; at least one processing device; and a memory containing instructions configured to instruct the at least one processing device to: allocate, by an operating system, memory from a namespace for use by an application program, wherein the namespace is a logical reference to one or more physical memory devices in which physical addresses are defined; bind the namespace to the first memory type; and in response to binding the namespace to the first memory type, adjust, by the operating system, a page table to map logical memory addresses in the namespace to the first memory device.

[0270] In one embodiment, the instructions are further configured to instruct the at least one processing device to access data at a first physical address in the first memory device corresponding to the logical memory address in the namespace using data from the page table.

[0271] In one embodiment, the data from the page table is cached in a translation lookaside buffer (eg, TLB 810), and a memory management unit (eg, MMU 316) accesses the translation lookaside buffer to translate the logical memory address to the first physical address.

[0272] In one embodiment, the system further includes a second memory device of a second memory type, wherein the instructions are further configured to instruct the at least one processing device to store data in the first memory device using the data from the page table by moving the data from the second memory device of the second memory type to the first memory device.

[0273] In one embodiment, a non-transitory machine-readable storage medium stores instructions that, when executed on at least one processing device, cause the at least one processing device to at least: create namespaces for memory devices of different memory types, the namespaces including a first namespace for a first memory device of a first memory type and a second namespace for a second memory device of a second memory type; bind data to the first namespace; and in response to binding the data to the first namespace, store the data in the first memory device.

[0274] In one embodiment, binding the data to the first namespace is performed in response to receiving a request for the first memory type (e.g., memory type 314) from an application; binding the data to the first namespace includes changing the binding of the data from the second namespace to the first namespace; and the latency of the first memory device is less than the latency of the second memory device.

[0275] In one embodiment, binding the data to the first namespace includes storing a mapping between a virtual address range of the first namespace and a first physical address of the first memory device; and storing the mapping includes storing metadata (e.g., metadata 320, 322) associating the virtual address range with the first memory device.

[0276] Conclusion

[0277] The present invention includes various apparatuses for performing the methods and implementing the systems described above, including data processing systems for performing these methods, and computer-readable media containing instructions that, when executed on a data processing system, cause the system to perform these methods.

[0278] The description and drawings are illustrative and should not be construed as limiting. Numerous specific details are described to provide a thorough understanding. However, in some cases, well-known or conventional details are not described to avoid obscuring the description. References to one or an embodiment of the present invention are not necessarily references to the same embodiment; such references mean at least one.

[0279] Throughout this specification, reference to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. The phrase "in one embodiment" throughout this specification does not necessarily refer to the same embodiment, nor does it necessarily refer to mutually exclusive separate or alternative embodiments of other embodiments. Furthermore, various features may be described that may be present in some embodiments but not in others. Similarly, various requirements may be described that may be required for some embodiments but not for others.

[0280] In this specification, various functions and operations may be described as being performed by or caused by software code to simplify the description. However, those skilled in the art will recognize that such statements mean that the functions are generated by the execution of the code by one or more processors, such as microprocessors, application specific integrated circuits (ASICs), graphics processors, and / or field programmable gate arrays (FPGAs). Alternatively, or in combination, dedicated circuit systems (such as logic circuit systems) may be used to implement the functions and operations with or without software instructions. Embodiments may be implemented using hard-wired circuit systems without software instructions, or in combination with software instructions. Therefore, the technology is not limited to any specific combination of hardware circuit systems and software, nor is it limited to any specific source of instructions executed by a computing device.

[0281] While some embodiments may be implemented in fully functioning computers and computer systems, the various embodiments are capable of being distributed as computing products in various forms and can be used regardless of the specific type of machine or computer-readable media used to actually effect the distribution.

[0282] At least some aspects of the disclosure may be embodied at least in part in software. That is, the techniques may be performed in a computing device or other system in response to its processor (e.g., a microprocessor) executing sequences of instructions contained in a memory (e.g., ROM, volatile RAM, non-volatile memory, cache, or remote storage).

[0283] The routines executed to implement the embodiments may be implemented as part of an operating system, middleware, a service delivery platform, a software development kit (SDK) component, a web service, or other specific application, component, program, object, module, or sequence of instructions referred to as a "computer program." The call interface for these routines may be exposed to the software development community as an application programming interface (API). A computer program typically includes one or more instructions that are set in various memories and storage devices in a computer at various times, and when read and executed by one or more processors in the computer, causes the computer to perform the operations necessary to execute the elements involved in various aspects.

[0284] Machine-readable media can be used to store software and data that, when executed by a computing device, causes the device to perform various methods. Executable software and data can be stored in various locations, including, for example, ROM, volatile RAM, non-volatile memory, and / or cache. Portions of the software and / or data can be stored in any of these storage devices. Additionally, data and instructions can be obtained from a centralized server or peer network. Different portions of the data and instructions can be obtained from different centralized servers and / or peer networks at different times and in different communication sessions or the same communication session. All data and instructions can be obtained prior to execution of the application. Alternatively, portions of the data and instructions can be obtained dynamically (in real time) as execution requires. Therefore, it is not necessary for all data and instructions to be on the machine-readable medium at a particular moment.

[0285] Examples of computer-readable media include, but are not limited to, recordable and non-recordable types of media, such as volatile and non-volatile memory devices, read-only memory (ROM), random access memory (RAM), flash memory devices, solid-state drive storage media, removable magnetic disks, magnetic disk storage media, optical storage media (such as compact disk read-only memory (CD ROM), digital versatile disks (DVD), etc.), and others. Computer-readable media can store instructions.

[0286] Generally speaking, a tangible or non-transitory machine-readable medium includes any mechanism that provides (e.g., stores) information in a form accessible by a machine (e.g., a computer, mobile device, network device, personal digital assistant, manufacturing tool, any device with one or more processors, etc.).

[0287] In various embodiments, hardwired circuitry may be used in combination with software and firmware instructions to implement the technology. Thus, the technology is not limited to any specific combination of hardware circuitry and software, nor to any specific source for the instructions executed by the computing device.

[0288] Although some of the figures illustrate several operations in a particular order, operations that are not order-dependent may be reordered and other operations may be combined or disassembled. Although some reordering or other groupings are specifically mentioned, others will be apparent to one of ordinary skill in the art, and thus, this is not an exhaustive list of alternatives. Furthermore, it should be recognized that the stages may be implemented in hardware, firmware, software, or any combination thereof.

[0289] In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will be apparent that various modifications may be made thereto without departing from the broader spirit and scope as set forth in the following claims. The specification and drawings are, therefore, to be regarded in an illustrative rather than a restrictive sense.

[0290] The various embodiments described herein can be implemented using a wide variety of different types of computing devices. As used herein, examples of "computing devices" include, but are not limited to, servers, centralized computing platforms, systems of multiple computing processors and / or components, mobile devices, user terminals, vehicles, personal communication devices, wearable digital devices, electronic information stations, general-purpose computers, electronic document readers, tablets, laptop computers, smartphones, digital cameras, residential household appliances, televisions, or digital music players. Additional examples of computing devices include devices that are part of what is known as the "Internet of Things" (IoT). Such "things" may have occasional interactions with their owners or administrators (who can monitor the things or modify the settings of these things). In some cases, such owners or administrators play the role of users with respect to the "things" devices. In some instances, a user's primary mobile device (e.g., an Apple iPhone) may be an administrator server with respect to the "things" device (e.g., an Apple Watch) worn by the user.

[0291] In some embodiments, the computing device may be a computer or host system implemented as, for example, a desktop computer, a laptop computer, a network server, a mobile device, or another computing device that includes memory and processing devices. The host system may include or be coupled to a memory subsystem such that the host system can read data from or write data to the memory subsystem. The host system may be coupled to the memory subsystem via a physical host interface. Generally speaking, the host system may access multiple memory subsystems via the same communication connection, multiple separate communication connections, and / or a combination of communication connections.

Claims

1. A method comprising: creating, by at least one processing device, namespaces for memory devices of different memory types, the namespaces including a first namespace for a first memory device of a first memory type and a second namespace for a second memory device of a second memory type; Binding data to the first namespace; and In response to binding the data to the first namespace, the data is stored in the first memory device. 2 . The method of claim 1 , wherein storing the data in the first memory device comprises moving the data from the second memory device to the first memory device. 3 . The method of claim 1 , wherein binding the data to the first namespace comprises changing a binding of the data from the second namespace to the first namespace. 4 . The method of claim 1 , wherein an operating system runs on the at least one processing device, and wherein binding the data to the first namespace is performed by the operating system in response to a request made by an application. The method according to claim 4 , wherein the first namespace is created by the operating system in response to a request made by the application. The method of claim 1 , wherein creating the namespaces comprises associating a respective virtual address with each namespace. 7 . The method of claim 6 , wherein binding the data to the first namespace comprises storing a mapping between a virtual address of the first namespace and a first physical address of the first memory device.

8. The method of claim 7, wherein the virtual addresses of the first namespace are in a first address range of an address space of the at least one processing device, and wherein storing the mapping comprises storing metadata associating the first address range with the first memory device.

9. A method according to claim 7, wherein the virtual address of the first namespace corresponds to a virtual page of a program managed by an operating system using a page table, and wherein storing the mapping includes generating a page table entry in the page table that maps the virtual address of the first namespace to the first physical address.

10. The method of claim 1, further comprising storing, by an operating system, in memory an association between a namespace and a data set bound to the namespace.

11. The method according to claim 1 , further comprising: determining an increase in priority of an application executing on the at least one processing device; wherein binding the data to the first namespace is performed in response to determining the increase in the priority, wherein binding the data to the first namespace comprises a change in binding from the second namespace to the first namespace, and wherein a latency of the first memory device is less than a latency of the second memory device.

12. The method of claim 1, wherein creating the first namespace comprises storing an identification of the first namespace in a memory of the first memory device.

13. The method of claim 1, further comprising receiving a request for an allocation of memory from an application, wherein the request specifies that data be stored in physical memory of the first memory type.

14. A system comprising: a first memory device of a first memory type; at least one processing device; and a memory containing instructions configured to instruct the at least one processing device to: allocating memory by an operating system from a namespace for use by an application, wherein the namespace is a logical reference to one or more physical memory devices in which physical addresses are defined; binding the namespace to the first memory type; and In response to binding the namespace to the first memory type, a page table is adjusted by the operating system to map logical memory addresses in the namespace to the first memory device.

15. The system of claim 14, wherein the instructions are further configured to instruct the at least one processing device to access data at a first physical address in the first memory device corresponding to the logical memory address in the namespace using data from the page table.

16. The system of claim 15, wherein the data from the page table is cached in a translation lookaside buffer, and wherein a memory management unit accesses the translation lookaside buffer to translate the logical memory address to the first physical address.

17. The system of claim 14, further comprising a second memory device of a second memory type, wherein the instructions are further configured to instruct the at least one processing device to store data in the first memory device using data from the page table by moving the data from the second memory device of the second memory type to the first memory device.

18. A non-transitory machine-readable storage medium storing instructions that, when executed on at least one processing device, cause the at least one processing device to at least: creating namespaces for memory devices of different memory types, the namespaces including a first namespace for a first memory device of a first memory type and a second namespace for a second memory device of a second memory type; Binding data to the first namespace; and In response to binding the data to the first namespace, the data is stored in the first memory device.

19. The non-transitory machine-readable storage medium of claim 18, wherein: Binding the data to the first namespace is performed in response to receiving a request for the first memory type from an application; Binding the data to the first namespace includes changing the binding of the data from the second namespace to the first namespace; and Functional characteristics of the first memory device are different from functional characteristics of the second memory device.

20. The non-transitory machine-readable storage medium of claim 18, wherein: Binding the data to the first namespace comprises storing a mapping between a virtual address range of the first namespace and a first physical address of the first memory device; and Storing the mapping includes storing metadata associating the virtual address range with the first memory device.

Citation Information

Patent Citations

  • Data retention component and framework

    US20140207741A1

  • Hybrid Checkpointed Memory

    US20170270041A1

  • Integrated heterogeneous solid state storage drive

    US20180260135A1