Page table related to memory type

Abstract

A computer system includes different types of physical memory devices that store randomly accessible data in memory in the computer system. In one approach, access to memory in an address space is maintained by an operating system of the computer system. A virtual page is associated with a first memory type. A page table entry is generated to map a virtual address of the virtual page to a physical address in a first memory device of the first memory type. The page table entry is used by a memory management unit to store the virtual page at the physical address.

Description

[0001] Related applications

[0002] This application claims priority to U.S. Patent Application No. 16 / 573,527, filed September 17, 2019, entitled “PAGETABLE HOOKS TO MEMORY TYPES”, the entire disclosure of which is hereby incorporated herein by reference. Technical Field

[0003] At least some of the embodiments disclosed herein generally relate to memory systems, and more specifically, but not limited to, page table entries that map virtual addresses of virtual pages to physical addresses in memory devices of different memory types. Background Technology

[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 non-volatile memory devices may include NAND flash memory devices or non-volatile 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 state of memory locations in main memory (such as allocated or free memory). Memory management further determines memory allocation for the various processes running on the operating system. When memory is allocated to a process, the operating system determines the memory location to be assigned to that process.

[0006] In one approach, the operating system uses paging to divide main memory into fixed-size units called page frames. The virtual address space of a software program is divided into pages of the same size. The hardware memory management unit maps these pages to frames in physical memory. In paging memory management, each process typically runs in its own address space.

[0007] In some cases, the Memory Management Unit (MMU) is called the Paging Memory Management Unit (PMMU). The MMU manages all memory references used by the operating system and performs the 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 page tables containing page table entries to map virtual page numbers to physical page numbers in main memory. In other cases, a cache of page table entries, called a translation lookaside buffer (TLB), is used to avoid the need to access page tables stored in main memory when mapping virtual addresses. When using virtual memory, contiguous ranges of virtual addresses can be mapped to several discontiguous blocks of physical memory.

[0009] In some cases, page table entries may contain information about page usage. Various instances include information about whether data has been written to the page, the last time the page was used, the type of process 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 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 memory device is accessed using the physical address retrieved from the search. 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 process identifiers to associate each page with a process. This association between process identifiers and virtual pages can help in selecting which pages to page out. For example, if a process's main code page has already been paged out, the likelihood of needing other pages belonging to that process immediately decreases.

[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-row memory module (DIMM), a small-outline DIMM (SO-DIMM), or a non-volatile dual-row memory module (NVDIMM). A memory subsystem may contain 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 the stored data. Some memory integrated circuits are non-volatile and retain the stored data even when no power is 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). Examples of volatile memory include dynamic random access memory (DRAM) and static random access memory (SRAM). Generally, a computer system can use a memory subsystem to store data at memory components 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 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 said type of device. The CPU of the computer system may run the operating system and device drivers to provide services and / or resources to application programs. The CPU may run application programs that use the services and / or resources. For example, an application program implementing a certain type of application program may instruct the CPU to store data in and retrieve data from the memory components of the memory subsystems.

[0014] A computer system's operating system allows applications to store data in or retrieve data from memory components of one or more memory subsystems of the computer system using virtual addresses. The operating system maps virtual addresses to physical addresses of one or more memory subsystems connected to the computer system's central processing unit (CPU). 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. The operating system can use paging techniques to access pages of memory in a storage device via pages in the memory module. At different times, the same virtual page of memory in the memory module can be used as a proxy to access different physical pages of memory in a storage device within the computer system or in another storage device.

[0016] A computer system may include a super manager (or virtual machine monitor) to create or provide virtual machines. A virtual machine is a computing device that is virtually implemented using resources and services available on the computer system. The super manager presents the virtual machine to the operating system as if the components of the virtual machine were dedicated physical components. The guest operating system runs within the virtual machine in a manner similar to the host operating system running on the computer system to manage the resources and services available to the virtual machine. The super manager allows multiple virtual machines to share the resources of the computer system and allows virtual machines to operate largely independently of each other on the computer. Attached Figure Description

[0017] The embodiments are illustrated by way of example (and not limitation) in the accompanying drawings, in which similar numbers indicate similar elements.

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

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

[0020] Figure 3 An example computer system is illustrated according to some embodiments, which stores metadata for accessing memory devices in a memory subsystem.

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

[0022] Figure 5 A host operating system is shown that uses memory bus access to access memory modules according to at least some embodiments.

[0023] Figure 6 The present invention illustrates a method for managing memory for processes in the address space of a computer system based on stored metadata, according to some embodiments, wherein the stored metadata associates a virtual address range for processes in the address space with a physical address for a memory device in the computer system.

[0024] Figure 7 This is a block diagram of an example computer system that can operate an embodiment of the present invention.

[0025] Figure 8 An example computer system is illustrated using one or more page tables to access memory devices on a memory bus, according to some embodiments.

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

[0027] Figure 10 This document demonstrates a method, according to some embodiments, for generating page table entries to map virtual addresses of virtual pages to physical addresses in memory devices of different memory types. Detailed Implementation

[0028] At least some embodiments herein relate to memory devices that access stored metadata to identify stored data in a memory system. In the various embodiments discussed herein, the metadata may be stored and accessed by various types of computer systems. In one example, the computer system is a system-on-a-chip (SoC) device that stores metadata for managing memory usage of one or more processes 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.

[0029] Other embodiments involve page table entries that map the virtual addresses of virtual pages to physical addresses in memory devices of different memory types. These embodiments are described in the following section entitled “Page Tables Related to Memory Types”.

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

[0031] 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 shorter than that 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.

[0032] In earlier computer systems that used different types of physical memory devices to store data in main memory, there was a technical problem that the processor lacked awareness of how memory used for various processes was actually mapped to memory devices. For example, the processor might assign virtual address ranges to processes. However, the processor was unaware of how these virtual address ranges were mapped to different memory devices.

[0033] In one instance, if a virtual address range for a process is mapped to a physical memory device (e.g., flash memory) that is significantly slower than other memory devices (e.g., DRAM), the process may be forced to run slowly because it cannot quickly access the data needed to continue execution from main memory. For example, the process might require a response from main memory to continue data computation or other processing (e.g., a response containing data for a read access request made by the processor to main memory to obtain data needed during the execution of the process). If the required data from main memory is actually stored in a slow physical memory device, then processing is significantly delayed while waiting for a response.

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

[0035] In some embodiments, the processor, operating system, and / or applications (such as those programmed by a software designer) may be initiated and / or acted upon by the computer system to avoid significant process latency attributable to slow memory access. For example, high-priority processes requiring fast memory response may be configured to run in DRAM.

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

[0037] In one example, memory device types include DRAM, NVRAM, and NAND flash. Process priorities are determined by the processor (e.g., based on the process's data usage patterns). Based on metadata about the memory mapped to address ranges of these memory device types, the processor assigns processes to address ranges with appropriate memory latency. For example, the processor may determine that a process has low, medium, or high priority. Based on the determination that a process has medium priority, the software and / or data associated with the process is stored in the address range corresponding to the physical memory in the NVRAM memory device type, which has medium latency.

[0038] In one example, the NVRAM device type is 3D XPoint memory. In another example, the NVRAM device type may 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 a computer system (e.g., NVDIMM-P). In another example, the NVRAM device is implemented using non-volatile 3D XPoint memory in a DIMM package.

[0039] In another instance, if the processor and / or operating system are not configured to automatically move the application to different address ranges in response to priority changes, the application's software code itself can be configured to read one or more values ​​from stored metadata. Based on the read values, the application itself can manage data storage, such that data is preferentially stored in the address range corresponding to the faster memory device. In one instance, the application can determine the relative latency of available memory devices in the computer system based on reading or otherwise providing access to stored metadata. In one instance, the stored metadata specifies which data resides on which of various memory devices with different latency times. By specifying the memory device in this way, the application can determine the latency for accessing specific data based on the memory device being used to store the data.

[0040] In one instance, an application on a mobile device reads stored metadata when the operating system (e.g., executing on a system-on-a-chip device) requests allocation of main memory. In another instance, the application makes a request for an address range in main memory corresponding to a specific type of memory device and / or a specific latency associated with a memory read or write access.

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

[0042] 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), and one or more processing devices (e.g., a CPU or a system-on-a-chip (SoC)). The computer system further includes memory containing instructions configured to instruct 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 that associates 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, a process including a first process and a second process based on the stored metadata, wherein data for the first process is stored in the first memory device, and data for the second process is stored in the second memory device.

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

[0044] In one embodiment, the application is not pre-programmed or otherwise configured to manage or dispose of memory allocation optimizations based on different types of memory devices. This may occur, for example, with legacy software programs. In this type of case, the operating system may be configured to manage memory allocation optimizations for the application.

[0045] In one instance, the operating system detects or otherwise determines one or more characteristics of an application. Based on these characteristics, the operating system uses stored metadata to assign one or more address ranges in main memory to the application. In one instance, characteristics are determined based on information provided by the application itself (e.g., when the application is launched on a mobile device). In another instance, characteristics are provided by the computing device, in addition to the computer system on which the application is executed. In one instance, a central repository is used to store and update databases or tables containing application characteristics. In one instance, a central server provides the operating system with instructions regarding the type of physical memory to be used.

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

[0047] In one embodiment, the stored metadata is used to identify the device storing the data. The memory subsystem has multiple physical memory devices (e.g., DRAM, NVRAM, and NAND flash) addressable by a processor (e.g., a System-on-a-Chip) in the memory address space. The metadata specifies which memory address regions are mapped to which physical memory devices. The metadata may be loaded into the DRAM and / or the processor (e.g., into the processor's cache) to determine which data resides on which device, and / or to estimate the latency for accessing individual data.

[0048] In one embodiment, an application executes on a mobile device with a processor that uses main memory. The application requests the mobile device's operating system to allocate a portion of main memory for its use. The allocated memory is in a logical / virtual memory space (e.g., the memory addresses are virtual as seen by the programmer and by the processor's execution unit). In one embodiment, virtual memory addresses are mapped to real / physical memory via page tables. A portion of the mapped data in the page tables is cached in a buffer in the processor. In one instance, the buffer is a Translation Lookaside Buffer (TLB).

[0049] In one embodiment, the computer system includes DRAM, NVRAM, and NAND flash memory devices. The processor of the computer system randomly accesses main memory by address. The addresses in main memory correspond to the physical location of data stored on these three types of memory devices. In one example, each of the 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 synchronized with the system bus that carries data between the CPU and the memory controller hub.

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

[0051] Computer system 120 may be a computing device, such as a mobile device, IoT device, desktop computer, laptop computer, network server, or the computing device including memory and processing. 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 intermediary components), wired or wireless, including connections such as electrical, optical, and magnetic connections. Examples of physical host interfaces include, but are not limited to, Serial Advanced Attachment Technology (SATA) interfaces, PCIe Quick Connect interfaces, Universal Serial Bus (USB) interfaces, Fibre Channel, Serial Attached SCSI (SAS), Dual Data Rate (DDR) memory buses, etc. The physical host interface can be used to transmit 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 access the memory components 109A to 109N using the NVM Quick Access (NVMe) interface. The physical host interface provides an interface for transmitting control, address, data, and other signals between the memory subsystem 110 and the computer system 120.

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

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

[0054] Generally, controller 116 can send commands or requests to memory subsystem 110 for desired access to memory components 109A to 109N. Controller 116 may further include interface circuitry for communicating with memory subsystem 110. The interface circuitry can translate responses received from memory subsystem 110 into information for computer system 120.

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

[0056] Memory components 109A to 109N may comprise various types of non-volatile memory components and / or any combination of volatile memory components. Examples of non-volatile memory components include NAND flash memory. In one example, each of memory components 109A to 109N may comprise one or more arrays of memory cells, such as single-level cell (SLC) or multi-level cell (MLC) (e.g., triple-level cell (TLC) or quadruple-level cell (QLC)). In some embodiments, a particular memory component may comprise both an SLC portion and an MLC portion of the memory cells. Each memory cell may store one or more data bits (e.g., data blocks) used by computer system 120.

[0057] While a non-volatile memory component, such as a NAND-type flash memory, is one example, memory components 109A to 109N can be based on any other type of memory, such as volatile memory. In some embodiments, memory components 109A to 109N can 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 bridged 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 with memristor technology, and a 3D XPoint array of non-volatile memory cells. The crosspoint array of non-volatile memory can perform bit storage based on changes in bulk resistance in conjunction with a stackable cross-grid data access array. Furthermore, compared to many flash-based memories, crosspoint non-volatile memory allows for in-situ write operations, where the non-volatile memory cells can be programmed without previously erasing them. Additionally, the memory cells of memory components 109A to 109N can be grouped into memory pages or data blocks that refer to the cells of the memory component used to store data.

[0058] The controller 115 of the memory subsystem 110 can communicate with memory components 109A to 109N to perform operations, such as reading, writing, or erasing data at memory components 109A to 109N, and other such operations (e.g., in response to commands scheduled on the command bus by the controller 116). The controller 115 may include hardware such as one or more integrated circuits and / or discrete components, buffer memories, or combinations thereof. The controller 115 may be a microcontroller, a special-purpose logic circuit system (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 means 117 (processor) configured to execute instructions stored in local memory 119. In the illustrated example, the local memory 119 of the controller 115 includes embedded memory configured to store instructions for performing operations of the memory subsystem 110, including handling communication between the memory subsystem 110 and the computer system 120. In some embodiments, local memory 119 may include memory registers storing memory indicators, retrieved data, etc. Local memory 119 may also include read-only memory (ROM) for storing microcode. Although Figure 1 The instance memory subsystem 110 is illustrated as including controller 115, but in another embodiment of the invention, the memory subsystem 110 may not include 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).

[0059] Generally, controller 115 can receive commands or operations from computer system 120 and can translate these commands or operations into instructions or appropriate commands to achieve the desired access to memory components 109A to 109N. Controller 115 may handle other operations such as wear leveling, scrap collection, error detection and error correction code (ECC) operations, encryption, caching, and address translation between logical block addresses and physical block addresses associated with memory components 109A to 109N. Controller 115 may further include a host interface circuitry for communicating with computer system 120 via a physical host interface. The host interface circuitry can translate commands received from the computer system into command instructions for accessing memory components 109A to 109N, and translate responses associated with memory components 109A to 109N into information for computer system 120.

[0060] The memory subsystem 110 may also include additional circuitry or components not shown. 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 decoder and column decoder) capable of receiving and decoding addresses from the controller 115 to access memory components 109A to 109N.

[0061] Computing environment 100 includes a metadata component 113 in computer system 120, which stores metadata (e.g., as discussed in the various embodiments above) used to identify storage devices storing data. A portion of metadata component 113 may reside on computer system 120 and / or memory subsystem 110. In one instance, a portion of the metadata is stored in local memory 119 and / or buffer 121. In another instance, a portion of the metadata is alternatively and / or additionally stored in a cache of controller 116 (e.g., in a translation lookahead buffer).

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

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

[0064] In one instance, 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 (e.g., DRAM on memory subsystem 110) to non-volatile memory via buffer 121.

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

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

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

[0068] Figure 2A mobile device 200 is shown according to some embodiments, which uses a memory bus 203 to access different types of memory in a memory module 205. Figure 2 Demonstrate computer systems 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 the memory subsystem 110 is shown in the figure.

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

[0070] Figure 2 The memory module 205 illustrated has various 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, the memory bus 203 may be a dual data rate bus. Generally, several memory modules (e.g., 205) may be coupled to the memory bus 203.

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

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

[0073] Generally, a memory subsystem (e.g., 205) may contain media, such as memory (e.g., 221…223). Memory (e.g., 221…223) may contain volatile memory, non-volatile memory (NVM), and / or combinations thereof. Processing device 118 may directly or indirectly write data to and read data from each of the memory subsystems (e.g., memory module 205).

[0074] In one embodiment, memory module 205 provides memory bus access to non-volatile or volatile memory 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, crosspoint memory.

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

[0076] In one embodiment, the memory module may be used to store data for a processor in a non-volatile or volatile storage medium. The memory module has a host interface that enables communication with a 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 communication 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.

[0077] As shown in the drawing Figure 2 The computer system is used to implement the mobile device. The processing device 118 can read data from or write data to the memory subsystem (e.g., 205).

[0078] The physical host interface can be used to transmit data between the processing device 118 and the memory subsystem (e.g., 205). The physical host interface provides an interface for transmitting control, address, data and other signals between the memory subsystem (e.g., 205) and the processing device 118.

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

[0080] 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), NOR flash memory, electrically erasable programmable read-only memory (EEPROM), and / or a cross-point array of non-volatile memory cells.

[0081] The memory subsystem (e.g., memory module 205) may have a controller (e.g., 227) that communicates with the memory (e.g., 221…223) to perform operations in response to requests, commands, or instructions from processing device 118, such operations 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 memories, or combinations thereof. The controller (e.g., 227) may be a microcontroller, a special-purpose logic circuit system (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.

[0082] The local memory of the controller (e.g., 227) may include embedded memory configured to store instructions for various processes, operations, logic flows, and routines used to control the operation of the memory subsystem (e.g., 205), including handling communication between the memory subsystem (e.g., 205) and the processing device 118, and other functions described in more detail below. The local memory of the controller (e.g., 227) may include read-only memory (ROM) for storing microcode and / or memory registers for storing, for example, memory indicators, retrieved data, etc.

[0083] although Figure 2The instance memory subsystem 205 is illustrated as including controller 227, but in another embodiment of the invention, the memory subsystem (e.g., 205) may not include 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)).

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

[0085] The memory subsystem (e.g., 205) may also include additional circuitry or components not shown. 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 addresses to access memory (e.g., 221…223).

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

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

[0088] In one embodiment, the processing device 310 of the computer system 300 accesses memory in the address space. In one instance, when executing one or more applications, the memory is the main memory used by the processing device 310. The processing device 310 uses addresses in the address space to access different memory devices.

[0089] In one embodiment, metadata 320, 322 associate a first address range of the address space with a memory device (e.g., DRAM 304) and a second address range of the address space with a different memory device (e.g., NVRAM 306 or NAND flash 308). In one instance, the latency of DRAM 304 is less than the latency of NVRAM 306 and NAND flash 308.

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

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

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

[0093] In one embodiment, metadata 322 stores data that associates address ranges in the virtual address space with physical addresses in the memory devices of the memory subsystem 302. In one example, metadata 322 stores address range 324 for NVRAM and address range 326 for NAND flash. 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 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.

[0094] In one embodiment, metadata 322 is stored as part of page table 328, which provides a virtual address-to-physical address mapping for memory management unit 316 of computer system 300. Processing device 310 provides virtual addresses to memory management unit 316, whose access translation look-ahead buffer 318 obtains physical addresses in one of the memory devices of memory subsystem 302.

[0095] In one embodiment, the metadata 322 and its components need not be sub-blocks of DRAM 304. It may instead reside in ROM (not shown) and / or other memory within the memory subsystem 302 (see DRAM SPD ROM), since the address range-to-media type mapping can be static for the memory subsystem 302. In one embodiment, for runtime inquiries, the metadata 322 may be masked in DRAM, but it will be dynamically generated upon power-up, or stored in and retrieved from a non-volatile component within the memory subsystem 302.

[0096] In one embodiment, the translation look-ahead buffer 318 is a cache that stores a portion of data from page table 328. In one instance, 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 look-ahead buffer 318 for access by memory management unit 316.

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

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

[0099] In one embodiment, processing device 310 determines a priority associated with application 312. An address range is allocated to application 312 based on the determined priority. In one instance, a faster memory device type is selected for use with the determined priority. Processing device 310 uses metadata 320, 322 to select the address range in which data will be physically stored in a memory device of the selected faster memory device type.

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

[0101] In one embodiment, processing device 310 determines the priority of application 312 based on observed characteristics associated with data access of application 312 in the address space. The observed characteristics can be used to allocate memory usage for application 312. In one embodiment, processing device 310 determines one or more latency periods associated with physical memory devices. Metadata 320, 322 stores data regarding the determined latency periods, which can be used by processing device 310 during initial allocation of main memory and / or changes to main memory allocation.

[0102] Figure 4 A memory module 401, configured according to some embodiments for a host computer system (not shown) to access memory buses of volatile memory 402 and non-volatile memory 404, is shown. 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.

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

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

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

[0106] In one example, memory module 401 is implemented as a DIMM. Non-volatile memory 404 is provided by a 3D XPoint memory package. In one example, page-in and page-out buffers (page-in / page-out) are used to copy data obtained from the 3D XPoint memory.

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

[0108] In one instance, the entire DDR address space of the non-volatile memory 404 is exposed to the host system. According to various embodiments, the controller of the computer system 120 (e.g., controller 116) can operate in the same manner as it accesses conventional DRAM (e.g., the same read / write and re-timing cycles).

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

[0110] In one embodiment, device driver 247 (e.g., back-end driver) is configured for memory access via super manager 245. In one instance, Figure 5 The system is implemented in Figures 1 to 3 In the computer system.

[0111] In one instance, the host operating system 241 is... Figure 1 Or 2 computer system processing device 118 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 (e.g., 247) that provide memory services using the memory (e.g., 221...223) of the memory subsystem (e.g., memory module 205 or memory subsystem 302).

[0112] In one embodiment, the back-end driver 247 maintains a mapping table 246. For example, the driver 247 maintains a mapping table 246 containing pages of data stored in DRAM 304, NVRAM 306, and NAND flash 308.

[0113] In one embodiment, the host operating system 241 includes a super manager 245 for deploying virtual machines 249. The virtual machines 249 have the capability to be used by the host operating system 241. Figures 1 to 3 Virtual hardware is implemented using the resources and services provided by the computing system's hardware. For example, the super manager 245 may use a portion of the memory (e.g., 221...223) of the memory subsystem (e.g., memory module 205) to deploy virtual memory as part of the virtual machine 249.

[0114] Virtual machine 249 allows guest operating system 243 to provide resources and / or services to applications running in guest operating system 243 (e.g., 251…253) in a manner similar to that of operating system 243 running on a physical computer, the physical computer having the same or similar set of hardware as deployed in the virtual machine. Super Manager 245 manages the mapping between virtual hardware deployed in the virtual machine and services of hardware in the computing system managed by host operating system 241.

[0115] Device driver 248 (e.g., front-side driver) communicates with back-side driver 247. When additional DDR capacity (e.g., capacity in DRAM or NVRAM) is available, drivers 247 and 248 can communicate for memory ballooning.

[0116] Figure 5 The illustration depicts a scenario where a virtual machine 249 is deployed by the super manager 245. Generally, the super manager 245 can deploy several virtual machines (e.g., 249) that can run the same guest operating system 243 or different guest operating systems. Different users and / or sets of applications can be assigned to use different virtual machines.

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

[0118] In one embodiment, device driver 247 may be configured to request a page in from slower memory (e.g., NVRAM) to faster memory (e.g., DRAM) for use by virtual machine 249. This request may be in response to an application (e.g., Figure 3 The request is made by application 312. After the page is requested, the page is made available in the faster memory by loading the page with data and / or transferring it from the slower memory to the faster memory. In one example, processing device 310 moves the page from the slower memory to the faster memory based on address range information stored as metadata 320, 322. In one example, the slower memory may be non-volatile memory 404 in memory module 401, and the faster memory may be volatile memory 402 in the same memory module 401.

[0119] In one embodiment, data transfer (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 the communication channels (e.g., memory bus 203) connected to the processing device 118. For example, under the control of the controller 227 in memory module 205, data can be copied from slower memory 223 (e.g., NVRAM or NAND flash) in memory module 205 to faster memory 221 (e.g., DRAM) in memory module 205 in response to one or more commands, requests, and / or instructions from the device driver 247.

[0120] In one embodiment, the super manager 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 the device driver 247 with information that can be used to manage pages in the memory to be used (e.g., 221…223…or 225). In one instance, the information provided includes stored metadata 320 or 322.

[0121] 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 given time. In one approach, for example, the memory address space is exposed to a guest operating system 243. In this hyper-manager environment, the guest operating system 243 sees the full storage capacity of the non-volatile memory (e.g., NVRAM and DRAM) in the DIMM.

[0122] In one instance, the host operating system 241 actively page-ins into the DDR DRAM. If a guest access to a non-existent page exists, a page seek error path in the host system's memory management unit (MMU) triggers driver 247 to cause the page to be loaded (page-in). In one instance, the page is loaded via a control register. Once the page is actually present in the DDR DRAM, driver 247 can set up an MMU mapping (via mapping table 246) so that the guest application can directly read and write the data.

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

[0124] In one embodiment, the back-end driver 247 operates as a memory-mode driver. No access to the NVRAM memory capacity of the memory module 502 occurs until driver 247 is loaded. During this operation as a memory-mode driver, the 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.

[0125] Driver 247 exposes the NVRAM memory to the guest operating system 243 and maintains page mappings (e.g., in mapping table 246). For example, driver 247 maintains a mapping between pages currently in DRAM and pages in NVRAM memory.

[0126] In one example, driver 247 sets up a memory management unit mapping table at the host system to map any pages currently stored in DRAM. If an access outside the mapped page triggers a page-in request, a page fault path from the client can be used. Page-out requests can be made to maintain some memory space in DRAM.

[0127] In one embodiment, operation is not limited to memory mode. Driver 247 can also operate as a frame-mode driver, for which NVRAM memory is exposed as frame-mode storage.

[0128] In one embodiment, memory module 502 maintains its own mapping table, containing a list of pages in an SRAM buffer (not shown). Once a page has been moved to the SRAM buffer, memory module 502 can return a page-in completion signal to the host system. This allows for a reduction in the host system's wait time for accessing those specific pages. Driver 247 ensures that the host will not access the page until its mapping is set, otherwise the page-in request will not be completed.

[0129] In one embodiment, driver 247 performs a page-out operation. In one instance, this operation is triggered as a thread. This operation swaps free pages out of DRAM memory and changes the mapping of available pages.

[0130] Figure 6 This document illustrates a method, according to some embodiments, for managing memory for processes in the address space of a computer system based on stored metadata, wherein the stored metadata associates a virtual address range for processes in the address space with physical addresses for memory devices in the computer system. For example, Figure 6 The method can be implemented in Figures 1 to 3 In the system.

[0131] Figure 6 The method can be performed by processing logic, which may include hardware (e.g., processing device, circuit system, dedicated logic, programmable logic, microcode, device hardware, integrated circuit, etc.), software (e.g., instructions that run or execute on the processing device), or a combination thereof. In some embodiments, Figure 6 The method comprises at least in part one or more processing devices (e.g. Figure 3 The processing device 310) performs the processing.

[0132] Although shown in a specific order or sequence, the order of the processes may be modified unless otherwise specified. Therefore, the illustrated embodiments should be understood as examples only, and the illustrated processes may proceed in different orders, and some processes may proceed in parallel. Furthermore, one or more processes may be omitted in various embodiments. Therefore, not all processes are necessary in every embodiment. Other processing flows are possible.

[0133] At block 601, the operating system maintains memory in the address space. Accessing memory involves accessing a first memory device and a second memory device using addresses in the address space. In one example, the operating system... Figure 3 The processing is performed on the processing device 310. In one example, the first memory device is DRAM 304 and the second memory device is NVRAM 306. In another example, the first memory device is NVRAM 306 and the second memory device is NAND flash 308.

[0134] At block 603, metadata is stored that associates a first address range of the 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 instance, the stored metadata is... Figure 3 The metadata is 320 and / or 322. In one instance, the first address range is address range 324, and the second address range is address range 326.

[0135] At block 605, processes running in the computer system are managed based on stored metadata. A process includes a first process and a second process. Data for the first process is stored in a first memory device, and data for the second process is stored in a second memory device. In one instance, data for the first process is stored in address range 324, and data for the second process is stored in address range 326. In another instance, data for the first process is stored in address ranges 320 and 322 corresponding to metadata stored in the physical memory of DRAM 304. In one instance, the computer system is computer system 120 or 300.

[0136] In one embodiment, the first and second processes are not necessarily entirely confined to the first and second memory devices, respectively. The address spaces of the processes may comprise multiple ranges with distinct access characteristics (e.g., low latency range 1 and non-volatile range 2). Therefore, in some cases, the processes may request allocations within each of the memory devices whose metadata is traced as needed.

[0137] In one embodiment, a method includes: a processing device of a computer system (e.g., Figure 3The processing device 310 accesses memory in an address space, wherein the memory devices of the computer system are accessed by the processing device using addresses in the address space; stores 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 associates 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 assigns the first address range to an application (e.g., application 312) executing on the computer system based on the stored metadata.

[0138] In one embodiment, assigning the first address range to the application is done in response to a request from the application.

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

[0140] In one embodiment, the first waiting time is less than the second waiting time, and the metadata is stored in the first memory device.

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

[0142] 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 side-view buffer 318), wherein the processing means queries the buffer to determine a physical address corresponding to a virtual address in the first address range.

[0143] In one embodiment, the computer system is a system-on-a-chip, and the buffer is a translation side-view buffer.

[0144] In one embodiment, the method further includes: providing memory characteristics of the first memory device and the second memory device 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.

[0145] In one embodiment, the method further includes receiving a requested wait time from the application, wherein assigning the first address range to the application is further based on the requested wait time.

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

[0147] In one embodiment, the first waiting time is less than the second waiting time; the application is assigned to the second address range before the first address range is assigned to the application; and the assignment of the first address range to the application is performed in response to determining an increase in priority associated with the application.

[0148] In one embodiment, the increase in priority associated with the application is determined based on one or more observations about the application's data access in the address space.

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

[0150] 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 that associates a first address range of the address space with the first memory device and associates a second address range of the address space with the second memory device; and manage, by the operating system, a process including a first process and a second process based on the stored metadata, wherein data for the first process is stored in the first memory device and data for the second process is stored in the second memory device.

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

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

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

[0154] In one embodiment, the read latency of the first memory device is less than that 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.

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

[0156] In one embodiment, a non-transitory machine-readable storage medium storage instruction, when executed on at least one processing device, causes the at least one processing device to at least: access memory in an address space, wherein the at least one processing device uses addresses in the address space to access memory devices of a computer system; store metadata that associates a first address range of the address space with a first memory device and associates 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 a first latency of the first memory device being less than a second latency of the second memory device; in response to providing the first data to the application, receive from the application a request 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.

[0157] Figure 7 This is a block diagram of an example computer system that can operate an embodiment of the present invention. Figure 7An example machine of computer system 600 is illustrated, containing a set of instructions executable to cause the machine to perform any or more of the methods discussed herein. In some embodiments, computer system 600 may correspond to a host system (e.g., Figure 1 Computer system 120), the host system includes, is coupled to, or utilizes a memory subsystem (e.g., Figure 1 The memory subsystem 110, or the metadata component 113, can be used to perform operations (e.g., execute instructions to perform operations corresponding to the reference). Figures 1 to 6 The operation of the described metadata component 113). In alternative embodiments, the machine may be connected (e.g., network connected) to other machines in a LAN, corporate intranet, inter-enterprise network, and / or network Internet. The machine may operate within the capacity of a server or client machine in a master-slave network environment, as a peer machine in a peer (or distributed) network environment, or as a server or client machine in a cloud computing infrastructure or environment.

[0158] A machine can be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular phone, a web browser, 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 specifies actions to be taken by the machine. Furthermore, although a single machine is depicted, the term "machine" also refers to any collection of machines that individually or jointly execute a set (or more) of instructions to perform any or more of the methods discussed herein.

[0159] 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).

[0160] Processing device 602 represents one or more general-purpose processing devices, such as microprocessors, central processing units, etc. 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 implementing other instruction sets, or a processor implementing a combination of instruction sets. Processing device 602 may also be one or more special-purpose processing devices, such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), network processors, etc. 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 communication via network 620.

[0161] The data storage system 618 may include a machine-readable storage medium 624 (also referred to as a computer-readable medium) storing one or more sets of instructions 626 or software embodying any one or more of the methods or functions described herein. During execution by the computer system 600, the instructions 626 may also reside wholly or at least partially in the main memory 604 and / or the processing device 602, which also constitute the machine-readable storage medium. The machine-readable storage medium 624, the data storage system 618, and / or the main memory 604 may correspond to... Figure 1 The memory subsystem 110.

[0162] In one embodiment, instruction 626 includes implementations corresponding to metadata component 113 (e.g., references to...). Figures 1 to 6 The described metadata component 113) contains functional instructions. Although the machine-readable storage medium 624 is shown as a single medium in the exemplary embodiment, the term "machine-readable storage medium" should be considered as a single medium or multiple media containing storage of one or more sets of instructions.

[0163] Page tables related to memory type

[0164] The following describes various embodiments relating to page table entries that map the virtual addresses of virtual pages to physical addresses in memory devices of different memory types. The generality of the following description is not limited to the various embodiments described above.

[0165] In previous memory management units (MMUs) of computer systems using different types of physical memory devices for data storage, there was a technical problem where the MMU was unaware of how to physically map memory used for various virtual pages to different types of memory devices (e.g., mapping virtual pages to physical addresses in DRAM versus NVRAM or flash memory). For example, the MMU did not store data on how each virtual page was mapped to a different type of memory device. Furthermore, the lack of knowledge about the memory type was merely a limitation. Even in uniform memory systems (e.g., in NUMA architectures), different physical addresses could have differences in access characteristics (differences that the MMU was unaware of).

[0166] In one instance, if virtual pages for a process are mapped to physical memory devices (e.g., flash memory) significantly slower than those for other memory devices (e.g., DRAM), the process may be forced to run slowly due to its inability to access data quickly. For example, the process might require virtual pages from main memory to continue processing. If the required virtual pages are actually stored in slow physical memory devices, the process will experience significant delays while waiting for access to the virtual pages.

[0167] The various embodiments described below provide technical solutions to one or more of the above-described 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., 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 storing the virtual page at the physical address in the first memory device using the page table entry. In one example, the page table entry has been copied to the cache of the memory management unit and / or the microprocessor. In one example, the page table entry has been copied to a translation look-ahead buffer (TLB) used by the memory management unit when storing the virtual page in the main memory of the central processing unit.

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

[0169] In one instance, an application or other software running on a computing device provides information to the operating system that identifies the type of memory the application or software needs 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 an 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).

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

[0171] Computer System 800 Figure 3 An example of computer system 300. The memory subsystem 802 is... Figure 3 An example of the memory subsystem 302. The memory bus 812 is... Figure 2 An example of memory bus 203.

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

[0173] Operating system 808 uses memory management unit (MMU) 316 to manage the memory of computer system 800. In one embodiment, virtual pages associated with an application containing 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 corresponding to the virtual page that the application needs to access.

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

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

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

[0177] In one embodiment, some page table entries from page tables 804, 806 are copied to translation lookahead buffer (TLB) 810. When mapping virtual addresses to physical addresses, MMU 316 first checks the TLB 810 for the page table entries corresponding to the virtual addresses. Page table entries in TLB 810 may also contain data copied from metadata 320, 322.

[0178] In one embodiment, application 312 requests memory allocation from processing device 310. In response, operating system 808 uses MMU 316 to generate page table entries that map the virtual addresses of application 312's virtual pages to physical addresses in the memory device. The memory device is selected to have memory type 314. In one embodiment, metadata 322 is used to select the memory device. In one embodiment, after generating the page table entries, a copy of the page table entries is stored in TLB 810 and / or the metadata 320, 322 is updated.

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

[0180] In response to the determination of a change, the 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 the higher priority of application 312. In response to the change to the new memory type, page table entries are updated to map the virtual address of the virtual page to a physical address in the new memory device of the new memory type. Then, the MMU 316 uses the updated page table entries to transfer the virtual page from the currently used memory device to the new memory device.

[0181] In one embodiment, the computer system 800 and / or processing device 310 is a system-on-a-chip (SoC). In one example, an SoC may be an integrated circuit or chip that includes any two or more components of an integrated 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 secondary storage. For example, an SoC may include a CPU, GPU, graphics and memory interface, hard disk, USB connectivity, random access memory, read-only memory, secondary storage, or any combination thereof on a single circuit die. Furthermore, when the processor chip is an SoC, the SoC may include at least a CPU and / or a GPU.

[0182] In one instance of a SoC, two or more components may be embedded on a single substrate or microchip. Generally, an SoC differs from a conventional motherboard-based architecture in that it integrates all its components into a single integrated circuit; whereas a motherboard houses and connects removable or replaceable components. Because two or more components are integrated onto 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, or an Internet of Things (IoT) device. In one embodiment, the memory subsystem 802 may be an SoC or included within an SoC. Furthermore, if the memory subsystem 802 is an SoC, the SoC may include at least a data processing unit.

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

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

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

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

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

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

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

[0190] Figure 10 The method can be performed by processing logic, which may include hardware (e.g., processing device, circuit system, dedicated logic, programmable logic, microcode, device hardware, integrated circuit, etc.), software (e.g., instructions that run or execute on the processing device), or a combination thereof. In some embodiments, Figure 10 The method comprises at least in part one or more processing devices (e.g. Figure 8 The processing device 310) performs the processing.

[0191] Although shown in a specific order or sequence, the order of the processes may be modified unless otherwise specified. Therefore, the illustrated embodiments should be understood as examples only, and the illustrated processes may proceed in different orders, and some processes may proceed in parallel. Furthermore, one or more processes may be omitted in various embodiments. Therefore, not all processes are necessary in every embodiment. Other processing flows are possible.

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

[0193] At box 1003, page table entries are generated. Page table entries map the virtual address of a virtual page to a physical address in a memory device of the first memory type. In one instance, page table entries reside in page table 804 or 806. In one instance, the memory device is DRAM 304, NVRAM 306, or NAND flash 308.

[0194] At box 1005, a page table entry is used to store the virtual page at a physical address in the memory device. In one example, memory management unit 316 uses a page table entry cached in translation look-ahead buffer 810 to store the virtual page.

[0195] In one embodiment, a method includes: associating a virtual page with a first memory type by at least one processing means (e.g., processing means 310 and / or memory management unit 316); generating a page table entry (e.g., page table entry 902) to map the 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.

[0196] In one embodiment, the method further includes: associating the virtual page with a second memory type by at least one processing means; 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.

[0197] In one embodiment, an operating system (e.g., operating system 808) runs on the at least one processing device, and the generation of the page table entry is performed by the operating system in response to associating the virtual page with the first memory type.

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

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

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

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

[0202] 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.

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

[0204] 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 updating the page table entry in response to selecting the second memory type to map the virtual address of the virtual page to a physical address in a second memory device of the second memory type.

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

[0206] In one embodiment, a process is executing on the at least one processing device, and the page table entry includes a process identifier of a first process using the virtual page.

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

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

[0209] 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 device 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 between a virtual page and a first memory type; determine that the first memory device corresponds to the first memory type; and generate page table entries to map the virtual address of the virtual page to a first physical address of the first memory device.

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

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

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

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

[0214] In one embodiment, the change in memory type is made in response to a request from an application running on the at least one processing device, or in response to a determination by the at least one processing device that the priority of a process or application has changed.

[0215] In one embodiment, a non-transitory machine-readable storage media storage instruction, when executed on at least one processing device, causes 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 the 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.

[0216] Conclusion

[0217] The present invention includes various apparatuses for carrying out the methods and systems described above, including a data processing system for carrying out these methods, and a computer-readable medium containing instructions that, when executed on the data processing system, cause the system to carry out these methods.

[0218] The descriptions and figures are illustrative and should not be considered limiting. Numerous specific details are described to provide a thorough understanding. However, in some cases, well-known or common details are not described to avoid obscuring the description. References to one or more embodiments of the invention are not necessarily references to the same embodiment; and such references mean at least one.

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

[0220] In this specification, various functions and operations may be described as being performed or caused by software code for the sake of simplicity. However, those skilled in the art will recognize that such expressions mean that the functions are generated by the execution of 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, functions and operations may be implemented using dedicated circuit systems (e.g., logic circuit systems) with or without software instructions. Embodiments may be implemented using hardwired circuit systems without software instructions, or in combination with software instructions. Therefore, the technology is not limited to any particular combination of hardware circuit systems and software, nor to any particular source of instructions executed by a computing device.

[0221] While some embodiments may be implemented on fully functional computers and computer systems, various embodiments are capable of being distributed as computing products in various forms and can be applied regardless of the specific type of machine or computer-readable medium used to actually affect the distribution.

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

[0223] The routines used to implement the embodiments may be implemented as part of an operating system, middleware, service delivery platform, software development kit (SDK) component, web service, or other specific application, component, program, object, module, or sequence of instructions referred to as a "computer program." The calling interface to 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 set at various times in various memories and storage devices within a computer, and when read and executed by one or more processors in the computer, causes the computer to perform operations necessary to perform elements involving various aspects.

[0224] 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. A portion of this 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 data and instructions can be obtained from different centralized servers and / or peer networks at different times and in different or the same communication sessions. All data and instructions can be obtained before the execution of the application. Alternatively, portions of data and instructions can be obtained dynamically (in real-time) when execution is required. Therefore, it is not necessary for all data and instructions to be on the machine-readable media at any given time.

[0225] Examples of computer-readable media include, but are not limited to, recordable and non-recordable 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 disks, disk storage media, optical storage media (e.g., optical disc read-only memory (CD-ROM), digital versatile optical disc (DVD), etc.), and others. Computer-readable media can store instructions.

[0226] Generally, tangible or non-transitory machine-readable media contain any means of providing (e.g., storing) information in a form accessible to machines (e.g., computers, mobile devices, network devices, personal digital assistants, manufacturing tools, any device having one or more processor sets, etc.).

[0227] In various embodiments, hard-wired circuitry systems can be used in combination with software and firmware instructions to implement the technology. Therefore, the technology is neither limited to any particular combination of hardware circuitry systems and software, nor to any particular source of instructions executed by a computing device.

[0228] Although some operations in the diagrams are depicted in a specific order, operations independent of order can be reordered and other operations can be combined or decomposed. While some reorderings or other groupings are specifically mentioned, others will be obvious to those skilled in the art, and therefore there is no exhaustive list of alternatives. Furthermore, it should be recognized that stages can be implemented in hardware, firmware, software, or any combination thereof.

[0229] In the foregoing description, the invention has been described with reference to specific exemplary embodiments thereof. It will be apparent that various modifications may be made therein without departing from the broader spirit and scope set forth in the following claims. Therefore, the description and drawings should be viewed in an illustrative rather than restrictive sense.

[0230] The various embodiments described herein can be implemented using a wide range of different types of computing devices. As used herein, examples of "computing device" include, but are not limited to, servers, centralized computing platforms, systems with 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 appliances, televisions, or digital music players. Additional examples of computing devices include devices that are part of what is called the "Internet of Things" (IoT). Such "IoT" devices may have incidental interactions with their owners or administrators (who can monitor or modify the settings of these IoT devices). In some cases, such owners or administrators act as users relative to the "IoT" devices. In some instances, a user's primary mobile device (e.g., an Apple iPhone) may be an administrator server relative to an "IoT" device worn by the user (e.g., an Apple Watch).

[0231] In some embodiments, the computing device may be a computer or a host system, implemented as, for example, a desktop computer, a laptop computer, a web server, a mobile device, or another computing device including memory and processing means. 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, 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 for managing memory, comprising: In response to a request received by the operating system from an application, a virtual page is allocated to the application and the virtual page is associated with a first memory type by at least one processing device; Page table entries are generated to map the virtual address of the virtual page to a physical address in a first memory device of the first memory type; The virtual page is stored at the physical address in the first memory device using the page table entry; The application is monitored by the operating system; Receive the second memory type associated with the application; and The page table entries are updated based on the monitoring to map the virtual address of the virtual page to a physical address in a second memory device of the second memory type.

2. The method according to claim 1, further comprising: The virtual page is associated with the second memory type by the at least one processing device; and The virtual page is transferred from the first memory device to the second memory device using an updated page table entry.

3. The method of claim 1, wherein the operating system runs on the at least one processing device, and the generation of the page table entry is performed by the operating system in response to associating the virtual page with the first memory type.

4. The method of claim 1, wherein the request from the application is provided to the first memory type.

5. The method of claim 1, further comprising managing the physical location of virtual pages stored in a memory device by the operating system of the computing device, wherein the memory device includes the first memory device and the second memory device of the second memory type, and wherein the power or performance characteristics of the first memory device are less than the corresponding power or performance characteristics of the second memory device.

6. The method according to claim 5, wherein the first memory type is dynamic random access memory, and the second memory type is non-volatile random access memory or flash memory.

7. The method of claim 1, further comprising: Determine the context of the operation associated with the at least one processing device; The second memory type is selected based on the determined context; and In response to selecting the second memory type, the page table entry is updated to map the virtual address of the virtual page to the physical address in the second memory device of the second memory type.

8. The method of claim 1, further comprising: The virtual page is associated with the second memory type by the at least one processing device; In response to associating the virtual page with the second memory type, the mapping data in the translation side-view buffer is updated; and The memory management unit transfers the virtual page from the first memory device to the second memory device based on the updated mapping data accessed in the translation side-view buffer.

9. The method of claim 1, wherein the process is executing on the at least one processing device, and the page table entry includes a process identifier of a first process using the virtual page.

10. The method of claim 1, wherein the page table entry includes data regarding usage patterns of one or more applications running on the at least one processing device.

11. The method of claim 10, wherein the data regarding the usage pattern is at least one of usage frequency or last usage time.

12. A memory system comprising: A first memory device of a first memory type; A second memory device of a second memory type; Page table, which stores 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 and the second memory device; At least one processing device; and A memory containing instructions configured to instruct the at least one processing device: In response to a request received by the operating system from an application, a virtual page is allocated to the application and the association of the virtual page with a first memory type is determined; Determine that the first memory device corresponds to the first memory type; Generate page table entries to map the virtual address of the virtual page to a first physical address of the first memory device; Receive the second memory type from the application; and The page table entry is updated to map the virtual address of the virtual page to a physical address in the second memory device.

13. The memory system of claim 12, wherein the at least one processing means uses a main memory having data stored on the memory means, and wherein determining the association of the virtual page with the first memory type is performed in response to a request for allocation of the main memory made by the application.

14. The memory system of claim 12, wherein the instructions are further configured to instruct the at least one processing device: The storage contains metadata that associates an address range in main memory with a physical address in the memory device. The determination that the first memory device corresponds to the first memory type is based on the stored metadata.

15. The memory system of claim 12, wherein the instructions are further configured to instruct the at least one processing means to use the page table entry to store the virtual page at the first physical address in the first memory means.

16. The memory system of claim 12, further comprising a memory management unit and a translation look-ahead buffer, wherein the instructions are further configured to instruct the at least one processing device: The mapping data in the translation side-view buffer is updated based on the change in memory type associated with the virtual page from the first memory type to the second memory type; and The memory management unit transfers the virtual page from the first memory device to the second memory device of the second memory type based on the updated mapping data.

17. The memory system of claim 16, wherein the change in memory type is performed in response to a request made by the application running on the at least one processing device, or in response to a determination made by the at least one processing device that the priority of a process or the application has changed.

18. A non-transitory machine-readable storage medium storing instructions, which, when executed on at least one processing device, cause the at least one processing device to at least: In response to a request received by the operating system from an application, a virtual page is allocated to the application and the virtual page is associated with a first memory type; Page table entries are generated to map the virtual address of the virtual page to a physical address in a first memory device of the first memory type; The virtual page is stored at the physical address in the first memory device using the page table entry; The application is monitored by the operating system; Receive the second memory type associated with the application; and The page table entries are updated based on the monitoring to map the virtual address of the virtual page to a physical address in a second memory device of the second memory type.

Images