Mapping of untyped memory access to typed memory access

Abstract

A computer system includes various types of physical memory devices that store randomly accessible data in the main memory of the computer system. In one approach, data is stored in memory at one or more logical addresses assigned to an application by an operating system. Data is physically stored in a first memory device of a first memory type (e.g., NVRAM). The operating system determines an access pattern for the stored data. In response to the determination of the access pattern, data is moved from the first memory device to a second memory device of a different memory type (e.g., DRAM).

Description

Technology Field

[0001] Related applications

[0002] This application claims priority to U.S. Patent Application No. 16 / 573,541, filed September 17, 2019, titled “Mapping of Untyped Memory Access to Typed Memory Access,” the entire disclosure of which is incorporated by reference into this application.

[0003] Technology field

[0004] At least some embodiments disclosed in this application relate generally to memory systems, more specifically to memory systems for mapping data to a type of memory device based on a data access pattern, but are not limited thereto. Background Technology

[0005] Data can be stored in the main memory of a computer system using various types of memory devices. 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.

[0006] In an operating system, memory management is responsible for managing the main memory of the computer system. Memory management tracks the status of memory locations in main memory (e.g., whether they are allocated or available). Memory management further determines memory allocation among the various processes running within the operating system. When memory is allocated to a process, the operating system determines the memory location to allocate to that process.

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

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

[0009] In some approaches, the MMU maps virtual page numbers to physical page numbers in main memory using a page table containing page table entries. In some cases, a cache of page table entries, referred to as the translation lookaside buffer (TLB), is used to avoid the need to access the page table stored in main memory when virtual addresses are mapped. When using virtual memory, the contiguous range of virtual addresses can be mapped to multiple non-contiguous blocks of physical memory.

[0010] In some cases, page table entries may contain information about page usage. Various examples include information regarding whether data has been written to the page, when the page was last used, the type of process capable of reading and writing the page (e.g., user mode or supervisor mode), and whether the page needs to be cached.

[0011] 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 address retrieved from the search is used to access the physical memory device. If the requested address is not in the TLB, the page table is accessed from main memory.

[0012] In some cases, the virtual memory management system uses a process identifier to associate each page with a process. The association between a virtual page and a process identifier can help select which page to page out. For example, if a process's main code page is paged out, the likelihood that another page belonging to that process will be immediately needed decreases.

[0013] More generally, a computer system may have one or more memory subsystems. A memory subsystem may be a memory module such as a DIMM (dual in-line memory module), SO-DIMM (small outline DIMM), or NVDIMM (non-volatile dual in-line memory module). A memory subsystem may include one or more memory components that store data. Memory components may be, for example, non-volatile memory components and volatile memory components. Examples of memory components include memory integrated circuits. Some memory integrated circuits are volatile and require power to retain stored data. Some memory integrated circuits are non-volatile and can retain stored data even when power is not supplied. Examples of non-volatile memory include flash memory, ROM (Read-Only Memory), PROM (Programmable Read-Only Memory), EPROM (Erasable Programmable Read-Only Memory), and EEPROM (Electronically Erasable Programmable Read-Only Memory) memory. Examples of volatile memory include DRAM (Dynamic Random-Access Memory) and SRAM (Static Random-Access Memory). Generally, a computer system can use a memory subsystem to store data in memory components and retrieve data from memory components.

[0014] 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 the computer's resources 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 on the computer; the operating system uses device drivers to provide resources and / or services provided by the device types. The central processing unit (CPU) of the computer system may execute the operating system and device drivers to provide services and / or resources to application programs. The central processing unit (CPU) may execute application programs that use the services and / or resources. For example, an application program implementing a type of application may instruct the central processing unit (CPU) to store data in a memory component of the memory subsystem and to retrieve data from the memory component.

[0015] The operating system of a computer system can enable application programs to use virtual addresses in memory to store data in memory components of one or more memory subsystems of the computer system or to retrieve data from memory components. The operating system maps virtual addresses to physical addresses of one or more memory subsystems connected to the central processing unit (CPU) of the computer system. The operating system translates memory accesses assigned to virtual addresses into physical addresses of memory subsystems.

[0016] The virtual address space can be partitioned into pages. Pages of virtual memory can be mapped to physical memory pages of the memory subsystem. The operating system can use paging technology to access memory pages of a storage device through memory pages of a memory module. In other instances, the same virtual page of memory in a memory module can be used as a proxy to access different physical pages of memory in a storage device or other storage devices of the computer system.

[0017] A computer system may include a hypervisor (or virtual machine monitor) for creating or provisioning virtual machines. A virtual machine is a computing device implemented virtually using the resources and services available in the computer system. The hypervisor provides the virtual machine to the operating system as if its components were dedicated physical components. A guest operating system runs on the virtual machine to manage the resources and services available to the virtual machine in a manner similar to a host operating system running on the computer system. The hypervisor enables multiple virtual machines to share the resources of the computer system and allows virtual machines to operate substantially independently of each other on the computer. [Prior Art][Patents] US 2016 / 0253259 A1 (2016.09.01.) US 2014 / 0207741 A1 (2014.07.24.) US 2019 / 0266106 A1 (2019.08.29.) Brief explanation of the drawing

[0018] Examples are illustrated in the attached drawings, where the same reference number represents a similar element, in an exemplary manner rather than as a limitation. FIG. 1 illustrates an exemplary computer system having a memory subsystem according to some embodiments. FIG. 2 illustrates a mobile device accessing different types of memory of a memory module using a memory bus according to some embodiments. FIG. 3 illustrates an exemplary computer system that stores metadata used to access a memory device of a memory subsystem according to some embodiments. FIG. 4 illustrates a memory module configured for memory bus access by a host computer system to volatile and non-volatile memory of a memory module according to some embodiments. FIG. 5 illustrates a host operating system that accesses a memory module using memory bus access, according to at least some embodiments. FIG. 6 illustrates a method for managing memory for a process in the address space of a computer system based on stored metadata that associates a physical address for a memory device of a computer system with a virtual address range for a process in the address space according to some embodiments. FIG. 7 is a block diagram of an exemplary computer system in which an embodiment of the present disclosure can be operated. FIG. 8 illustrates an exemplary computer system that uses one or more page tables to access memory devices on a memory bus according to some embodiments. FIG. 9 illustrates an exemplary page table having page table entries according to some embodiments. FIG. 10 illustrates a method for generating a page table entry to map a virtual address of a virtual page to a physical address of a memory device of a different memory type, according to some embodiments. FIG. 11 illustrates an exemplary computer system that uses a namespace table to map namespaces to different memory types for the physical memory of a computer system according to some embodiments. FIG. 12 illustrates an exemplary namespace table having records mapping namespaces to different types of memory for a computer system according to some embodiments. FIG. 13 illustrates a method for binding data to a namespace of a memory system having physical memory of different memory types, according to some embodiments. FIG. 14 illustrates an exemplary computer system that uses an access table to map memory access to different types of physical memory, according to some embodiments. FIG. 15 illustrates an exemplary access table having records used to map memory access to different types of memory, according to some embodiments. FIG. 16 illustrates a method for mapping memory access to memory based on an access pattern according to some embodiments. Specific details for implementing the invention

[0019] At least some embodiments of the present application relate to accessing stored metadata to identify memory devices of a memory system in which data is stored. In various embodiments as described in the present application, the metadata may be stored and accessed by various types of computer systems. In one example, the computer system is a system-on-chip (SoC) device that stores metadata for managing memory usage by one or more processes running on the SoC device. In one example, a mobile device uses the SoC device to manage main memory allocation for one or more applications running on the mobile device.

[0020] Another embodiment relates to a page table entry that maps the virtual address of a virtual page to the physical address of a memory device of a different memory type. This embodiment is described in the section below titled “Page table hook for memory type”.

[0021] Another embodiment relates to binding data to a namespace of a memory system having physical memory of different memory types. This embodiment is described in the section below titled "Data Binding to a Namespace".

[0022] Additional embodiments relate to mapping data to a type of memory device based on an access pattern to the stored data. In one embodiment, an operating system determines an access pattern (e.g., frequency of read and / or write access) to data stored in a first type of memory device. Based on the access pattern, the operating system moves data physically stored in the first type of memory device (e.g., NVRAM) to another type of memory device (e.g., a faster DRAM device or a slower NAND flash depending on the use case).

[0023] In another embodiment, an access pattern is determined for data stored in a first address range corresponding to a first type of memory device. Based on the determined access pattern, the data is stored in a second address range corresponding to a different type of memory device. Such an embodiment is described in the section below titled “Mapping of data to memory types based on access patterns”.

[0024] Conventional computer systems often use different types of memory devices to store data. Typically, one type of memory device used is DRAM, which is generally considered to provide high-speed read and write access. DRAM is commonly used to store data in the main memory of a computer system.

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

[0026] In conventional computer systems that use different types of physical memory devices to store data in main memory, a technical problem exists where the processor does not recognize how memory for various processes is actually mapped to memory devices. For example, the processor can assign a virtual address range to a process. However, the processor does not know how that virtual address range is mapped to different memory devices.

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

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

[0029] In some embodiments, a processor, an operating system, and / or an application (programmed by a software designer) may initiate and / or perform actions by the computer system to avoid significant process delays caused by slow memory access. For example, high-priority processes requiring fast memory response may be configured to run in DRAM.

[0030] In another example, the priority of an application running on a mobile device can be monitored. When the priority of an application increases (e.g., changes 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 the slow memory device and move the application to a new address range corresponding to the fast memory device.

[0031] In one example, memory device types include DRAM, NVRAM, and NAND flash. The priority of a process is determined by the processor (e.g., based on the process's usage pattern). Based on stored metadata regarding address range mapping for these memory device types, the processor assigns the process to an address range with appropriate memory latency. For example, the processor can determine whether the process has low, medium, or high priority. Based on the determination that the process has medium priority, the software and / or data associated with the process are stored in an address range corresponding to a physical storage of an NVRAM memory device type with medium latency.

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

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

[0034] In one example, an application on a mobile device reads stored metadata when requesting main memory allocation by an operating system (e.g., running on a system-on-chip device). In one example, the application requests an address range of main memory corresponding to a specific type of memory device and / or a specific latency associated with memory read or write access.

[0035] In one example, 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 the allocation of fast memory. In a second context of the mobile device, the application requests the allocation of slow memory. In one example, in response to the detection of a predetermined context, the application initiates or performs a request for a change in memory allocation. In one example, the application determines the change in context based on an updated query made regarding stored metadata (e.g., by a processor) and / or data provided to the application by the processor of the computer system (e.g., behavioral characteristics of the mobile device).

[0036] In one embodiment, the computer system comprises 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., CPU or System-on-Chip (SoC)). The computer system further comprises memory containing instructions, wherein the instructions access memory of an address space maintained by an operating system on one or more processing devices—access includes accessing the first memory device and the second memory device using addresses of the address space—; store metadata associating a first address range of the address space with the first memory device and associating a second address range of the address space with the second memory device; and are configured to instruct the operating system to manage a process including a first process and a second process based on the stored metadata—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.

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

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

[0039] In one example, the operating system detects or otherwise determines one or more attributes of an application. Based on the attributes, the operating system uses stored metadata to allocate one or more address ranges of main memory to the application. In one example, the attributes are determined based on information provided by the application itself (e.g., when the application is launched on a mobile device). In another example, the attributes are provided by a computing device other than the computer system on which the application is running. In one example, a central repository is used to store and update a database or an application's attribute table. In one example, a central server provides the operating system with indications regarding the type of physical memory to use.

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

[0041] In one embodiment, stored metadata is used to identify the device where data is stored. The memory subsystem has a number of physical memory devices (e.g., DRAM, NVRAM, and NAND flash) that can be addressed by a processor (e.g., SoC) in the memory address space. The metadata is used to specify which memory address region is mapped to which physical memory device. The metadata may be loaded into the DRAM and / or the processor (e.g., loaded into the processor's cache) to determine which data is in which device, and / or may be used to estimate the latency of access to each data.

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

[0043] In one embodiment, a computer system includes DRAM, NVRAM, and NAND flash memory devices. A processor of the computer system randomly accesses main memory by address. Addresses within main memory correspond to physical locations of data storage on these three types of memory devices. In one example, each device is accessed by the processor using a synchronous memory bus. In one example, the DRAM is a synchronous dynamic random access memory (SDRAM) having an interface synchronized with a system bus that transmits data between the CPU and the memory controller hub.

[0044] FIG. 1 illustrates an exemplary computing environment (100) having a memory subsystem (110) according to some embodiments. The memory subsystem (110) may include a medium such as memory components (109A to 109N). The memory components (109A to 109N) may be volatile memory components, non-volatile memory components, or a combination 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 the memory subsystem (110) and read data from the memory subsystem (110).

[0045] The computer system (120) may be a computing device, such as a mobile device, an IoT device, a desktop computer, a laptop computer, a network server, or a computing device including a memory and processing device. The computer system (120) may include or be coupled to a memory subsystem (110) so that the computer system (120) can read data from or write data to the memory subsystem (110). The computer system (120) may be coupled to the memory subsystem (110) via a physical host interface. As used in this application, "coupled to" generally refers to a connection between components, which may be an indirect communication connection (e.g., without intervening components), whether wired or wireless, including connections such as electrical, optical, magnetic, etc. Examples of physical host interfaces include, but are not limited to, SATA (serial advanced technology attachment) interfaces, PCIe (peripheral component interconnect express) interfaces, USB (universal serial bus) interfaces, Fibre Channel, SAS (Serial Attached SCSI), DDR (double data rate) memory buses, etc. Physical host interfaces may be used to transmit data between a computer system (120) and a memory subsystem (110). The computer system (120) may additionally use an NVMe (NVM Express) interface to access memory components (109A to 109N) when the memory subsystem (110) is coupled to the computer system (120) via a PCIe interface.The physical host interface can provide an interface for transmitting control, address, data, and other signals between the memory subsystem (110) and the computer system (120).

[0046] FIG. 1 illustrates a memory subsystem (110) as an example. Generally, a computer system (120) may access multiple memory subsystems through 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 a processing device (118) via a memory bus.

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

[0048] Generally, the controller (116) may transmit commands or requests to the memory subsystem (110) for desired access to memory components (109A to 109N). The controller (116) may further include an interface circuit for communicating with the memory subsystem (110). The interface circuit may convert a response received from the memory subsystem (110) into information for the computer system (120).

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

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

[0051] While a non-volatile memory component such as NAND-type flash memory is one example, the memory components (109A to 109N) may be based on any other type of memory, such as volatile memory. In some embodiments, the memory components (109A to 109N) may be, but are not limited to, random access memory (RAM), read-only memory (ROM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), phase change memory (PCM), magnetic random access memory (MRAM), spin transfer torque (STT)-MRAM, ferroelectric transistor random access memory (FeTRAM), ferroelectric RAM (FeRAM), conductive bridge RAM (CBRAM), resistive random access memory (RRAM), oxide-based RRAM (OxRAM), negative-or (NOR) flash memory, electrically erasable programmable read-only memory (EEPROM), nanowire-based non-volatile memory, memory incorporating memristor technology, and a 3D XPoint array of non-volatile memory cells. A cross-point array of non-volatile memory can perform bit storage based on changes in bulk resistance in conjunction with a stackable cross-gridded data access array. Additionally, unlike many flash-based memories, cross-point non-volatile memory can perform write in-place operations, wherein non-volatile memory cells can be programmed without the non-volatile memory cells being erased in advance. Furthermore, memory cells of memory components (109A to 109N) can be grouped as memory pages or data blocks, which may mean units of memory components used to store data.

[0052] A controller (115) of the memory subsystem (110) may communicate with memory components (109A to 109N) to perform operations such as reading data, writing data, or erasing data, and other such operations on memory components (109A to 109N) (e.g., in response to a command 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 memory, or a combination thereof. The controller (115) may be a microcontroller, a special-purpose logic circuit (e.g., a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.), or other suitable processor. The controller (115) may include a processing device (117) (processor) configured to execute instructions stored in local memory (119). In the illustrated example, the local memory (119) of the controller (115) includes an embedded memory configured to store instructions for performing various processes, operations, logic flows, and routines that control the operation of the memory subsystem (110), including processing communication between the memory subsystem (110) and the computer system (120). In some embodiments, the local memory (119) may include memory registers that store memory pointers, fetched data, etc. The local memory (119) may also include read-only memory (ROM) for storing microcode. Although the exemplary memory subsystem (110) of FIG. 1 is illustrated as including the controller (115), in other embodiments of the present disclosure, the memory subsystem (110) may not include the controller (115) and may instead rely on external control (e.g., provided by an external host or a processor or controller separate from the memory subsystem).

[0053] Generally, the controller (115) can receive commands or operations from the computer system (120) and convert the commands or operations into instructions or appropriate instructions to achieve desired access to the memory components (109A to 109N). The controller (115) may be responsible for other operations associated with the memory components (109A to 109N), such as wear leveling operations, garbage collection operations, error detection and error correction code (ECC) operations, encryption operations, caching operations, and address translation between logical block addresses and physical block addresses. The controller (115) may further include a host interface circuit for communicating with the computer system (120) through a physical host interface. The host interface circuit can not only access the memory components (109A to 109N) by converting the commands received from the computer system into instruction commands, but also convert the responses associated with the memory components (109A to 109N) into information about the computer system (120).

[0054] The memory subsystem (110) may also include additional circuitry or components not exemplified. In some embodiments, the memory subsystem (110) may include a cache or buffer (121) (e.g., DRAM or SRAM) capable of receiving an address from the controller (115) and decoding the address to access memory components (109A through 109N), and an address circuitry (e.g., a row decoder and a column decoder).

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

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

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

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

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

[0060] In some embodiments, the controller (115) and / or processing device (117) of 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 circuit portion that implements the metadata component (113).

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

[0062] FIG. 2 illustrates a mobile device (200) accessing different types of memory of a memory module (205) using a memory bus (203) according to some embodiments. FIG. 2 illustrates a computer system having different types of memory. The computer system of FIG. 2 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 an example of the memory subsystem (110) illustrated in FIG. 1.

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

[0064] The memory module (205) illustrated in FIG. 2 includes a plurality of types of memory (e.g., 221 and 223). For example, memory of type A (221) (e.g., DRAM) is faster than memory of type B (223) (e.g., NVRAM). For example, the memory bus (203) may be a double data rate bus. Generally, multiple memory modules (e.g., 205) may be combined to the memory bus (203).

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

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

[0067] Generally, a memory subsystem (e.g., 205) may include a medium such as memory (e.g., 221, …, 223). The memory (e.g., 221, …, 223) may include volatile memory, non-volatile memory (NVM), and / or a combination thereof. A processing device (118) may write data to each of the memory subsystems (e.g., memory modules (205)) and read data directly or indirectly from the memory subsystems (e.g., memory modules (205)).

[0068] In one embodiment, the memory module (205) uses a buffer (121) to provide memory bus access to non-volatile memory or volatile memory. In one example, the memory module (205) is a DIMM coupled to a mobile device (200) via a DDR bus. The storage medium is, for example, cross-point memory.

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

[0070] In one embodiment, the memory module may be used to store data for the processor on a non-volatile or volatile storage medium. The memory module has a host interface that implements communication with a mobile device using a communication channel. In one embodiment, the memory module (205) has a controller (227) that executes, for example, firmware to perform an operation 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.

[0071] As illustrated, the computer system of FIG. 2 is used to implement a mobile device. The processing device (118) can read data from a memory subsystem (e.g., 205) or write data to a memory subsystem.

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

[0073] Generally, a memory subsystem (e.g., a memory module (205)) comprises a printed circuit board connecting a set of memory devices, such as a memory integrated circuit, that provides 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.

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

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

[0076] The local memory of the controller (e.g., 227) may include embedded memory configured to store instructions for executing various processes, operations, logic flows, and routines that 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 more specifically 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 pointers, fetched data, etc.

[0077] Although the exemplary memory subsystem (205) of FIG. 2 is illustrated as including a controller (227), in other embodiments of the present disclosure, the memory subsystem (e.g., 205) may not include a controller (e.g., 227) and may instead rely on external control (e.g., provided by an external host or a processor or controller separate from the memory subsystem (e.g., 205)).

[0078] Generally, a controller (e.g., 227) may receive a command, request, or instruction from a processing device (118) according to a standard communication protocol for a communication channel (e.g., 203), and may convert the command, request, or instruction into a detailed instruction or an appropriate instruction within a memory subsystem (e.g., 205) according to a standard protocol to achieve 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 a logical address and a physical address associated with memory (e.g., 221, …, 223). The controller (e.g., 227) may further include a host interface circuit for communicating with the processing device (118) via a physical host interface. The host interface circuit can convert a command received from the processing device (118) into a command for accessing a memory device (e.g., 221, …, 223), and can also convert a response associated with the memory device (e.g., 221, …, 223) into information about the processing device (118).

[0079] The memory subsystem (e.g., 205) may also include additional circuitry or components not exemplified. In some implementations, the memory subsystem (e.g., 205) may include a cache or buffer (e.g., DRAM) and address circuitry (e.g., row decoder and column decoder), and the address circuitry may receive an address from a controller (e.g., 227) and decode this address to access memory (e.g., 221, …, 223).

[0080] In one example, the memory bus (203) has one or more connectors for providing power to a memory subsystem (e.g., 205) and / or communicating with the memory subsystem (e.g., 205) via a predetermined protocol; the memory subsystem (e.g., 205) has one or more connectors for receiving power, data, and commands from the processing device (118). In one example, the processing device (118) may run one or more operating systems to provide a service including memory access in which a portion of the memory of a computer system (e.g., a page stored in NVRAM) is accessed using synchronous memory access.

[0081] FIG. 3 illustrates an exemplary computer system (300) that stores metadata (320) used to access memory devices of a memory subsystem (302) according to some embodiments. Memory devices accessed in the memory subsystem (302) include DRAM (304), NVRAM (306), and NAND flash (308). In one embodiment, the computer system (300) stores metadata (322) in a DRAM (304) used to access memory devices alternatively and / or additionally.

[0082] In one embodiment, a processing device (310) of a computer system (300) accesses memory in an address space. In one example, the memory is main memory used by the processing device (310) when running one or more applications. The processing device (310) accesses different memory devices using addresses in the address space.

[0083] In one embodiment, metadata (320, 322) associates 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 example, the latency of the DRAM (304) is smaller than the latency of the NVRAM (306) and NAND flash (308).

[0084] An application running on a processing device (310) includes an application (312), which is configured to include a memory type (314). When the application (312) is initially launched, the application (312) provides the memory type (314) to the processing device (310) along with a request for memory allocation in the main memory of the computer system (300).

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

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

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

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

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

[0090] In one embodiment, the processing device (310) provides the application (312) with memory characteristics of different memory devices. The application (312) performs a request for memory allocation based on the provided memory characteristics.

[0091] In one embodiment, the processing device (310) receives a requested latency from the application (312). Based on the requested latency, an address range is assigned to the application (312).

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

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

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

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

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

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

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

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

[0100] In one example, the host system has read / write access rights to arbitrary DRAM or NVRAM addresses using normal DDR4 timing. For example, the host can generate random traffic according to DDR4 rules during these times.

[0101] In one example, the entire DDR address space of the non-volatile memory (404) is exposed to the host system. According to various embodiments, a controller of the computer system (120) (e.g., controller (116)) may operate in the same manner as for accessing a conventional DRAM (e.g., the same read / write and refresh timing cycles).

[0102] FIG. 5 illustrates a host operating system (241) accessing a memory module (502) using a memory bus according to at least some embodiments. The memory module (502) includes a buffer (410). The buffer (410) is an example of a buffer (121). In one example, the buffer (410) stores at least a portion of metadata (322) and / or a page table (328). Commands and data are received from the host operating system (241) via a host interface (406). In one example, the host operating system (241) runs on a computer system (120 or 300).

[0103] In one embodiment, a device driver (247) (e.g., a backend driver) is configured for memory access through a hypervisor (245). In one example, the system of FIG. 5 is implemented in the computer system of FIG. 1 through 3.

[0104] In one example, the host operating system (241) is executed on the processing device (118) of the computer system of FIG. 1 or FIG. 2 or the processing device (310) of FIG. 3. The host operating system (241) includes one or more device drivers (e.g., 247) that provide memory services using memory of a memory subsystem (e.g., 221, …, 223), such as a memory module (205) or a memory subsystem (302).

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

[0106] In one embodiment, a host operating system (241) includes a hypervisor (245) that provisions a virtual machine (249). The virtual machine (249) has virtual hardware implemented through resources and services provided by the host operating system (241) using the hardware of the computing system of FIGS. 1 through 3. For example, the hypervisor (245) may provision virtual memory as part of the virtual machine (249) using a portion of the memory of a memory subsystem (e.g., 221, …, 223), such as a memory module (205).

[0107] The virtual machine (249) enables the guest operating system (243) to provide resources and / or services to applications (e.g., 251, …, 253) running on the guest operating system (243) in the same way as the operating system (243) running on a physical computing machine having the same or similar set of hardware that the guest operating system (243) provisions in the virtual machine. The hypervisor (245) manages the mapping between the virtual hardware provisioned in the virtual machine and the hardware services of the computing system managed by the host operating system (241).

[0108] A device driver (248) (e.g., a front-end driver) communicates with a back-end driver (247). The driver (247) and the driver (248) may communicate for memory ballooning if additional DDR capacity (e.g., capacity of DRAM or NVRAM) is available.

[0109] FIG. 5 illustrates an instance in which a virtual machine (249) is provisioned by a hypervisor (245). Generally, the hypervisor (245) may provision multiple virtual machines (e.g., 249) capable of running the same guest operating system (243) or different guest operating systems. Different sets of users and / or application programs may be assigned to use different virtual machines.

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

[0111] In one embodiment, the device driver (247) may be configured to request page-in of a page from a slower memory (e.g., NVRAM) to a faster memory (e.g., DRAM) for use by the virtual machine (249). This request may be made in response to a request from an application (e.g., the application (312) of FIG. 3). After the page is requested, the page becomes available in the faster memory by loading and / or transferring the page of data from the slower memory to the faster memory. In one example, the 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 the non-volatile memory (404) of the memory module (401) and the faster memory may be the volatile memory (402) of the same memory module (401).

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

[0113] In one embodiment, the hypervisor (245) requests the device driver (247) to access memory (e.g., 221, …, 223) of the memory subsystem (e.g., memory module (205)) and also provides the device driver (247) with information that can be used to manage pages of memory (e.g., 221, …, 223, …, or 225) to be used. In one example, the provided information includes stored metadata (320 or 322).

[0114] In one example, the driver (247) is a memory mode driver used to access the memory address space of a memory module (502) (e.g., DIMM). The 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 hypervisor environment, the guest operating system (243) sees the total storage capacity of non-volatile memory (e.g., NVRAM and DRAM) in the DIMM.

[0115] In one example, only multiple pages in the DDR DRAM are actively paged in via the host operating system (241). If there is guest access to a non-existent page, the page fault path of the host system's memory management unit (MMU) triggers the driver (247) to cause the loading (page-in) of the page. In one example, the page is loaded via a control register. When the page actually exists in the DDR DRAM, the driver (247) can set up an MMU mapping (via the mapping table (246)) so that the guest application can directly read and write the corresponding data.

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

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

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

[0119] In one example, the driver (247) sets up a memory management unit mapping table in the host system to map any page currently stored in the DRAM. If access to a page outside the mapped page exists to trigger a page-in request, the guest's page fault path may be used. A page-out request may be performed to retain some memory space in the DRAM.

[0120] In one embodiment, the operation is not limited to memory mode. The driver (247) may also operate as a block mode driver in which NVRAM memory is exposed as a block mode storage.

[0121] In one embodiment, the memory module (502) maintains its own mapping table containing a list of pages in an SRAM buffer (not shown). The memory module (502) may return a page-in completion signal to the host system when a page is moved to the SRAM buffer. These allow for a reduction in the latency of the host system accessing a specific page. The driver (247) ensures that the host does not access the corresponding page(s) until the mapping is established or until the page-in request is completed.

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

[0123] FIG. 6 illustrates a method for managing memory for a process in the address space of a computer system based on stored metadata that associates a physical address for a memory device of a computer system with a virtual address range for a process in the address space according to some embodiments. For example, the method of FIG. 6 may be implemented in the system of FIG. 1 to 3.

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

[0125] Although illustrated in a specific sequence or order, the order of the processes may be modified unless otherwise specified. Accordingly, the illustrated embodiments should be understood for illustrative purposes only, and the illustrated processes may be performed in a different order, and some processes may be performed in parallel. Additionally, one or more processes may be omitted in various embodiments. Therefore, not all processes are required in all embodiments. Other process flows are possible.

[0126] In block 601, the operating system maintains memory in an address space. The memory is accessed by using addresses in the address space to access a first memory device and a second memory device. In one example, the operating system runs on the processing device (310) of FIG. 3. In one example, the first memory device is a DRAM (304) and the second memory device is an NVRAM (306). In one example, the first memory device is an NVRAM (306) and the second memory device is a NAND flash (308).

[0127] In 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 example, the stored metadata is the metadata (320 and / or 322) of FIG. 3. In one example, the first address range is address range 324, and the second address range is address range 326.

[0128] In block 605, a process running in a computer system is managed based on stored metadata. The 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 example, data for the first process is stored in address range 324, and data for the second process is stored in address range 326. In one example, data for the first process is stored in address ranges of metadata (320, 322) corresponding to physical memory storage of the DRAM (304). In one example, the computer system is a computer system (120 or 300).

[0129] In one embodiment, the method comprises the steps of accessing memory of an address space by a processing device of a computer system (e.g., a processing device (310) of FIG. 3)—the memory device of the computer system is accessed by the processing device using an address of the address space—; storing metadata (e.g., metadata (320 and / or 322)) that associates a first address range of the address space with a first memory device (e.g., DRAM (304)) and 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 assigning the first address range to an application (e.g., application (312)) running on the computer system based on the stored metadata.

[0130] In one embodiment, the step of allocating a first address range to an application is performed in response to a request by the application.

[0131] In one embodiment, the method further comprises: providing an indication that a first latency is greater than a second latency in response to a first request by an application; receiving a second request made by the application based on this indication; and assigning a second address range to the application in response to receiving the second request.

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

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

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

[0135] In one embodiment, the computer system is a system-on-chip device, and the buffer is a conversion index buffer.

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

[0137] In one embodiment, the method further includes the step of receiving a requested latency from an application, and the step of allocating a first address range to the application is further based on the requested latency.

[0138] In one embodiment, the method further includes the step of determining a priority associated with an application, and the step of assigning a first address range to the application is additionally based on the priority.

[0139] In one embodiment, the first latency is smaller than the second latency; before assigning the first address range to the application, the application is assigned to the second address range; and the step of assigning the first address range to the application is performed in response to determining an increase in priority associated with the application.

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

[0141] In one embodiment, the method further includes the step of determining a latency associated with a memory device by a processing device, and the step of storing metadata further includes the step of storing the determined latency.

[0142] In one embodiment, the system comprises a first memory device; a second memory device; at least one processing device; and a memory containing instructions, wherein the instructions access memory of an address space maintained by an operating system in at least one processing device—access includes accessing the first memory device and the second memory device using addresses of the address space—; store metadata associating a first address range of the address space with the first memory device and associating a second address range of the address space with the second memory device; and are configured to instruct the operating system to manage a process including a first process and a second process based on the stored metadata—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.

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

[0144] In one embodiment, a first process corresponds to a first application; an instruction is further configured to instruct at least one processing device to receive a request from the first application indicating the type of memory to be used to store data; and a first memory device is selected to store data for the first process based on the indicated memory type.

[0145] In one embodiment, the system further includes a buffer for storing metadata, and the operating system receives a virtual address of a first address range from a first process and accesses the buffer to determine the physical address of a first memory device corresponding to the virtual address.

[0146] In one embodiment, the read latency of the first memory device is smaller than the read latency of the second memory device, and the instruction is further configured to instruct at least one processing device to store metadata in the first memory device.

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

[0148] In one embodiment, a non-transient machine-readable storage medium stores an instruction, which, when executed on at least one processing device, causes at least one processing device to access memory in at least an address space—a memory device of the computer system is accessed by at least one processing device using an address in the address space—; stores 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; provides first data to an application running on the computer system indicating that a first latency of the first memory device is smaller than a second latency of the second memory device; receives a request from an application to store second data associated with the application in the first memory device in response to providing the first data to the application; queries the stored metadata to provide a result in response to the application's request to store the second data; and based on this result, causes the second data to be stored in the first memory device.

[0149] FIG. 7 is a block diagram of an exemplary computer system in which an embodiment of the present disclosure may operate. FIG. 7 illustrates an exemplary machine of a computer system (600) in which a set of instructions for causing the machine to perform one or more of the methodologies described in the present application may be executed. In some embodiments, the computer system (600) may correspond to a host system (e.g., the computer system (120) of FIG. 1) that includes, is coupled to, or utilizes a memory subsystem (e.g., the memory subsystem (110) of FIG. 1) or may be used to perform an operation of a metadata component (113) (e.g., to execute instructions for performing an operation corresponding to the metadata component (113) described with reference to FIG. 1 through 6). In an alternative embodiment, the machine may be connected (e.g., network connection) to another machine on a LAN, intranet, extranet, and / or the Internet. The machine can operate as a server or client machine in a client-server network environment, as a peer machine in a peer-to-peer (or distributed) network environment, or as a server or client machine in a cloud computing infrastructure or environment.

[0150] A machine may be a personal computer (PC), tablet PC, set-top box (STB), personal digital terminal (PDA), mobile phone, web appliance, server, network router, switch or bridge, Internet of Things (IOT) device, or any machine capable of executing a set of instructions (sequentially or otherwise) that specifies an action to be performed on said machine. Additionally, although a single machine is exemplified, the term “machine” should also be considered to include any set of machines that execute a set of instructions (or a number of sets) individually or jointly to perform any one or more of the methodologies described in this application.

[0151] An exemplary computer system (600) includes a processing device (602), a main memory (604) (e.g., dynamic random access memory (DRAM), static random access memory (SRAM), such as read-only memory (ROM), flash memory, synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM)), and a data storage system (618) that communicates with each other through a bus (630) (which may include multiple buses).

[0152] The processing device (602) represents one or more general-purpose processing devices, such as a microprocessor, a central processing unit, etc. More specifically, the processing device may be a Compound Instruction Set Computing (CISC) microprocessor, a Reduced Instruction Set Computing (RISC) microprocessor, a Very Long Instruction Word (VLIW) microprocessor, or a processor implementing another instruction set or a combination of instruction sets. The processing device (602) may also be one or more special-purpose processing devices, such as an Application-Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Digital Signal Processor (DSP), a network processor, etc. The processing device (602) is configured to execute instructions (626) for performing the operations and steps described in this application. The computer system (600) may further include a network interface device (608) for communicating through a network (620).

[0153] The data storage system (618) may include a machine-readable storage medium (624) (also known as a computer-readable medium) in which one or more instruction sets (626) or software that implement any one or more of the methodologies or functions described in this application are stored. The instruction (626) may also reside in the main memory (604) and / or the processing device (602) in whole or at least partially while being executed by the computer system (600), main memory (604), and processing device (602) that 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 the memory subsystem (110) of FIG. 1.

[0154] In one embodiment, the instruction (626) includes instructions for implementing a function corresponding to a metadata component (113) (e.g., the metadata component (113) described with reference to FIGS. 1 through 6). Although the machine-readable storage medium (624) is depicted as a single medium in exemplary embodiments, the term “machine-readable storage medium” should be considered to include a single medium or multiple media storing one or more sets of instructions.

[0155] Page table hooks for memory types

[0156] Various embodiments relating to page table entries that map the virtual address of a virtual page to the physical address of a memory device of a different memory type are now described below. The generality of the following description is not limited to the various embodiments described above.

[0157] In conventional memory management units of computer systems that use different types of physical memory devices to store data, there is a technical problem in that the MMU does not know how memory for various virtual pages is physically mapped to different types of memory devices (e.g., whether a virtual page is mapped to a physical address in DRAM versus NVRAM or in flash memory). For example, the MMU does not store data regarding how each virtual page is mapped to a different type of memory device. Furthermore, memory type ignorance is just one limitation. Different physical addresses can have differences in access characteristics (which the MMU does not know) even within homogeneous memory systems (e.g., in a NUMA architecture).

[0158] In one example, if a virtual page for a process is mapped to a physical memory device (e.g., flash memory) that is much slower than other memory devices (e.g., DRAM), the process is inevitably forced to run slowly due to the inability to access data quickly. For instance, a process may require a virtual page in main memory to continue processing. If the required virtual page is actually stored on a slow physical memory device, the process experiences significant delay while waiting to access the virtual page.

[0159] The various embodiments described below provide technical solutions to one or more of the above technical problems. In one embodiment, the method comprises the steps of 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 for mapping the virtual address of the virtual page to a physical address of a first memory device of the first memory type; and storing the virtual page at a physical address of the first memory device using the page table entry. In one example, the page table entry was copied to a cache of a memory management unit and / or a microprocessor. In one example, the page table entry was copied to a translation lookaside buffer (TLB) used by the memory management unit when storing the virtual page in the main memory of the central processing unit.

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

[0161] In one example, an application or other software running on a computing device provides the operating system with information identifying the type of memory that the application or other software wishes to use 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 an application's request for an NVRAM memory type, a virtual page is allocated to the application. The physical address corresponding to the allocated virtual page is used to store data in the NVRAM device (e.g., a crosspoint memory device).

[0162] FIG. 8 illustrates an exemplary computer system (800) that uses 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).

[0163] The computer system (800) is an example of the computer system (300) of FIG. 3. The memory subsystem (802) is an example of the memory subsystem (302) of FIG. 3. The memory bus (812) is an example of the memory bus (203) of FIG. 2.

[0164] An operating system (808) runs on a processing device (310). The operating system (808) allocates the main memory of the processing device (310) to various applications. These applications include applications (312) having a memory type (314). In one example, the memory type (314) is embedded in the code of the application (312). In one example, the memory type (314) is provided to the processing device (310) by a different computing device (not shown). In one example, the different computing device is a server that provides the memory type (314) in response to a request by the application (312) for memory allocation.

[0165] The operating system (808) manages memory for the computer system (800) using a memory management unit (MMU) (316). In one embodiment, a virtual page associated with an application, including an application (312), is mapped to physical memory residing in the memory subsystem (802). The MMU (316) accesses a page table entry to determine the physical address of memory corresponding to the virtual page that the application needs to access.

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

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

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

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

[0170] In one embodiment, an application (312) requests memory allocation from a processing device (310). In response, the operating system (808) uses the MMU (316) to create a page table entry to map the virtual address of a virtual page for the application (312) to a physical address of a memory device. The memory device is selected to be a memory type (314). In one embodiment, metadata (322) is used to select the memory device. In one embodiment, after creating the page table entry, a copy of the page table entry is stored in the TLB (810) and / or the metadata (320, 322) is updated.

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

[0172] In response to a change decision, the operating system (808) associates one or more virtual pages of the application (312) with a new memory type. For example, in response to a decision to give the application (312) a higher priority, the memory type for the application (312) may be changed from NVRAM to DRAM. In response to the change to the new memory type, a page table entry is updated to map the virtual address of the virtual page to the physical address of the new memory device of the new memory type. Then, the MMU (316) uses the updated page table entry to transfer the virtual page from the currently used memory device to the new memory device.

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

[0174] In one example of an SoC, two or more components may be embedded on a single substrate or microchip (chip). Generally, an SoC differs from a conventional motherboard-based architecture in that it integrates all components into a single integrated circuit, whereas a motherboard accommodates and connects components that are detachable or replaceable. Because two or more components are integrated on a single substrate or chip, an SoC consumes less power and occupies much less area than a multi-chip design with the same function. In some embodiments, the memory system or subsystem described in this application may be connected to or part of the SoC in a mobile computing device (such as a smartphone), an embedded system, and an Internet of Things (IoT) device. In one embodiment, the memory subsystem (802) may be an SoC or may be included therein. Additionally, if the memory subsystem (802) is an SoC, the SoC may include at least a data processing unit.

[0175] FIG. 9 illustrates an exemplary page table (900) having page table entries (902, 904) according to some embodiments. Each page table entry (902, 904) includes a virtual address, a corresponding physical address, and a memory type. In one example, the memory type is memory type 314. In one example, the memory type (314) is used to update the page table entry in response to a new allocation or allocation change of main memory for 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.

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

[0177] In one embodiment, a process identifier for each page table entry is used to identify a process running on a processing device (310) that uses a virtual page at a virtual address. For example, the process identifier is a unique identifier for each process running on a computer system (800).

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

[0179] In one embodiment, each page table entry may include a memory device identifier. In one example, the memory device identifier uniquely identifies a physical memory device in which data corresponding to a virtual address is stored. In one example, the memory device identifier uniquely corresponds to a DRAM (304) or an NVRAM (306).

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

[0181] FIG. 10 illustrates a method for generating a page table entry to map a virtual address of a virtual page to a physical address of a memory device of a different memory type, according to some embodiments. For example, the method of FIG. 10 may be implemented in the system of FIG. 8 or the computer system (600) of FIG. 7.

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

[0183] Although illustrated in a specific sequence or order, the order of the processes may be modified unless otherwise specified. Accordingly, the illustrated embodiments should be understood for illustrative purposes only, and the illustrated processes may be performed in a different order, and some processes may be performed in parallel. Additionally, one or more processes may be omitted in various embodiments. Therefore, not all processes are required in all embodiments. Other process flows are possible.

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

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

[0186] In block 1005, using a page table entry, a virtual page is stored at a physical address of a memory device. In one example, the memory management unit (316) stores the virtual page using a page table entry cached in a translation index buffer (810).

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

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

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

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

[0191] In one embodiment, a first memory type (e.g., memory type (314)) is provided with a request from an application.

[0192] In one embodiment, the method further comprises the step of managing a physical location for a virtual page stored in a memory device by an operating system of a computing device, wherein the memory device comprises a first memory device and a second memory device of a second memory type, and the latency of the first memory device is smaller than the latency of the second memory device.

[0193] In one embodiment, differences other than and / or additional therein may exist between the first and second memory devices. In one example, 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 durable memory. Examples of differences in memory characteristics between different memory devices or types or memories may include performance, power, durability, error rate, and / or combinations thereof. In some cases, for example, such differences may exist between devices of the same memory type (e.g., error rates vary for different chips of the same memory type used to store data for a process).

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

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

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

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

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

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

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

[0201] In one embodiment, the system comprises: a first memory device; a page table storing a page table entry that maps a virtual address to a physical address of a memory device of a different memory type—the memory device includes the first memory device—at least one processing device; and a memory containing instructions, wherein the instructions are configured to instruct at least one processing device to determine the association of a virtual page to a first memory type; to determine that the first memory device corresponds to the first memory type; and to instruct the device to create a page table entry for mapping a virtual address of a virtual page to a first physical address of the first memory device.

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

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

[0204] In one embodiment, the instruction is further configured to instruct at least one processing device to store a virtual page at a first physical address of a first memory device using a page table entry.

[0205] In one embodiment, the system further comprises a memory management unit (e.g., memory management unit (316)) and a conversion index buffer, and the instruction is further configured to update the mapping data of the conversion index buffer based on a change in the memory type associated with a virtual page from a first memory type to a second memory type to at least one processing device; and to instruct the memory management unit to transfer the virtual page from a first memory device to a second memory device of a second memory type based on the updated mapping data.

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

[0207] In one embodiment, a non-transient machine-readable storage medium stores an instruction, which, when executed on at least one processing device, causes at least one processing device to associate at least a virtual page with a first memory type; generate a page table entry for mapping a virtual address of a virtual page to a physical address of a first memory device of the first memory type; and use the page table entry to store the virtual page at a physical address of the first memory device.

[0208] Binding Data to a Namespace

[0209] Various embodiments relating to binding data to namespaces in memory systems having physical memory of different memory types are now described below. The generality of the following description is not limited to the various embodiments described above.

[0210] In conventional memory systems, main memory is made accessible to applications by the operating system and is allocated from a single logical address space (e.g., virtual addresses in the address space). In particular, the operating system does not allow applications access to arbitrary mapping controls; therefore, applications cannot control which type of memory is used to store data. Instead, the operating system and / or processor control mapping through page tables and translation index buffers. Page tables define the mapping between logical address pages and pages in physical memory units located in the computer system's memory devices. The total size of page tables is relatively large. Therefore, most page tables are stored in memory (e.g., DRAM in main memory). Some of the data from the page tables currently used to locate physical memory addresses is cached in the translation index buffer of the processor / memory controller.

[0211] The aforementioned situation regarding conventional memory systems creates a technical problem where applications cannot access specific data in a timely manner due to the high latency of the actual physical memory devices storing the data. Consequently, the execution of applications may be delayed for extended periods. In some cases, this delay can lead to system failures requiring timely responses or other actions. For example, a real-time control system may fail due to slow data access from main memory. In one example, navigation control in an autonomous vehicle may fail due to excessive latency in the part of main memory where critical data is stored.

[0212] Applications that cannot control the mapping of main memory usage to specific physical memory devices also prevent the application from selecting memory with higher reliability. This creates a technical problem where critical data may be lost due to memory functional failures (e.g., failure to access data from physical memory devices with higher failure rates).

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

[0214] In one embodiment, data access is performed by the operating system through a namespace table managed by the operating system. In one embodiment, the namespace table assigns names to memory addresses in main memory. In one embodiment, names are assigned to a range of virtual addresses in the address space of main memory used by the application. In one embodiment, namespaces are identified by namespace identifiers (e.g., using any identifiers namespace A, namespace B, and namespace C, where each identifier is associated with a different type of memory).

[0215] In one embodiment, namespaces are used for memory access. Each namespace is a named logical reference to a set of memory units where memory addresses are defined. An application allocates memory from a namespace. The operating system provides a service that an application can call to bind and / or rebind a namespace to a specific type of memory (e.g., DRAM, NVRAM, NAND flash). When a namespace is bound to a memory type, the operating system manipulates one or more page tables to map the logical memory address of the namespace to a physical memory unit of that specific memory type in the computer system. When a memory unit is accessed through the logical address of a namespace, data from one or more page tables is loaded and cached in the translation index buffer of the processor / memory controller for translation to a physical memory address.

[0216] In one embodiment, namespaces are created on various types of memory devices (e.g., DRAM, NVRAM, and NAND flash). An application can move data to a desired memory device by dynamically changing the binding between a data set and a namespace. In one embodiment, an operating system detects a change in the binding and enables the data to be moved. In one embodiment, the operating system causes a memory management unit to update a page table so that data is moved from the currently used memory device to a desired memory device.

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

[0218] In one embodiment, the kernel of an operating system controls all hardware devices of a computer system with the help of firmware and device drivers. The kernel manages memory access for programs in random access memory (RAM) and determines which programs can access specific hardware resources.

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

[0220] In one embodiment, the allocation of memory space by the kernel is based at least partially on namespace data provided by an application. In one example, the application provides a namespace corresponding to a memory type. In response, the kernel allocates memory space corresponding to a physical memory device of that memory type. In one example, the kernel uses virtual memory addressing (e.g., paging or partitioning) to determine the memory that each program can access at any given time.

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

[0222] The computer system (1100) is an example of the computer system (800) of FIG. 8. The memory subsystem (1102) is an example of the memory subsystem (802) of FIG. 8.

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

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

[0225] In one embodiment, each memory device may store various data associated with an allocated namespace. Each namespace data is represented in FIG. 11 as "Namespace A data", "Namespace B data", and "Namespace C data". In one example, the namespace data includes a namespace identifier. In one example, the namespace data includes a physical address range corresponding to a DRAM (304). In one example, the namespace data includes a portion of data from metadata (320, 322). In one example, the namespace data includes a portion of data from a page table (804).

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

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

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

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

[0230] An existing or newly created namespace is bound to a memory type. In response to binding the namespace to a memory type, one or more page tables are adjusted to map logical memory addresses and the namespace to memory devices of the memory type. In one example, page table (806) and / or page table (804) are updated in response to binding the namespace to a memory type.

[0231] In one embodiment, the operating system (808) creates a namespace for a memory device. Data is bound to the namespace. In one example, the data is identified by a virtual address range. In response to binding the data to the namespace, the data is stored in the memory device associated with the created namespace. In one example, binding the data to the namespace includes storing a mapping between the virtual address of the namespace and the physical address of the memory device.

[0232] In one embodiment, one or more virtual addresses of a namespace correspond to virtual pages of a process managed by an operating system (808) using a page table (804). In one example, the page table (804) includes a page table entry that maps a virtual address of a namespace to a physical address of a memory device.

[0233] FIG. 12 illustrates an exemplary namespace table (1200) having records (1202, 1204, 1206) mapping namespaces to different types of memory for a computer system according to some embodiments. In one example, the computer system is computer system 1100. Namespace table 1200 is an example of a namespace table (1104).

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

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

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

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

[0238] FIG. 13 illustrates a method for binding data to a namespace of a memory system having physical memory of different memory types, according to some embodiments. For example, the method of FIG. 13 may be implemented in the system of FIG. 11.

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

[0240] Although illustrated in a specific sequence or order, the order of the processes may be modified unless otherwise specified. Accordingly, the illustrated embodiments should be understood for illustrative purposes only, and the illustrated processes may be performed in a different order, and some processes may be performed in parallel. Additionally, one or more processes may be omitted in various embodiments. Therefore, not all processes are required in all embodiments. Other process flows are possible.

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

[0242] In block 1303, the namespace is bound to a memory type. In one example, the namespace is bound to memory type 314. In one example, the binding of the namespace to the memory type is stored in the namespace table (1104).

[0243] In block 1305, in response to binding the namespace to a memory type, the page table is adjusted to map the logical memory address of the namespace to a memory device of the memory type. In one example, the page table (804) and / or the page table (806) is adjusted. In one example, the logical memory address is the virtual address of a virtual page of the application (312). In one example, the memory device is a DRAM (304).

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

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

[0246] In one embodiment, binding data to the first namespace includes a change to bind data from the second namespace to the first namespace.

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

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

[0249] In one embodiment, creating a namespace includes associating each virtual address (e.g., virtual addresses of page tables (804, 806); virtual addresses of metadata (320, 322)) with each namespace.

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

[0251] In one embodiment, the virtual address of the first namespace is in the first address range of the address space of one processing device, and storing the mapping includes storing metadata (e.g., metadata (320, 322)) that associates the first address range with the first memory device.

[0252] In one embodiment, a virtual address of a first namespace corresponds to a virtual page of a process managed by an operating system using a page table (e.g., page table (804, 806)), and storing the mapping includes creating a page table entry in the page table that maps the virtual address of the first namespace to a first physical address.

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

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

[0255] In one embodiment, creating the first namespace includes storing the identity of the first namespace in the memory of the first memory device (e.g., storing a namespace identifier and / or other identity as part of the “Namespace A data” of FIG. 11).

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

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

[0258] In one embodiment, the instruction is further configured to instruct at least one processing device to access data at a first physical address of a first memory device corresponding to a logical memory address of a namespace using data from a page table.

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

[0260] In one embodiment, the system further comprises a second memory device of a second memory type, and the instruction is further configured to instruct at least one processing device to store data in the first memory device using data from a page table by moving data from the second memory device of the second memory type to the first memory device.

[0261] In one embodiment, a non-transient machine-readable storage medium stores an instruction, and when this instruction is executed on at least one processing device, the at least one processing device creates a namespace for at least different memory types of memory devices—the namespace includes a first namespace for a first memory device of a first memory type and a second namespace for a second memory device of a second memory type; binds data to the first namespace; and in response to binding data to the first namespace, stores data in the first memory device.

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

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

[0264] Mapping of data to memory types based on access patterns

[0265] Various embodiments related to mapping data to memory device types based on data access patterns are now described below. The generality of the following description is not limited to the various embodiments described above.

[0266] In conventional memory systems, memory allocated to application data (e.g., random access memory allocated to executable code and / or work data for the application) is not explicitly partitioned for specific memory types (e.g., applications are not coded to use a specific memory type for work data). In one example, legacy applications were written without implementing concepts for any different types of memory, such as DRAM, NVRAM, and NAND flash. Consequently, all application data is allocated by the operating system without any consideration or management of how memory access affects performance during the execution of legacy applications. In many cases, data needs to be read or written frequently but will be read from or written to relatively slow memory (e.g., NAND flash devices instead of DRAM devices). Therefore, there can be a significant mismatch between memory device latency for various types of data and memory access requirements.

[0267] The aforementioned situation regarding conventional memory systems creates a technical problem where applications cannot access specific data in a timely manner due to high latency in the actual physical memory devices storing certain critical data. As a result, application execution may be delayed for extended periods. In some cases, such delays can cause failures in computer systems that require timely responses or other actions. For example, real-time control systems for machinery (e.g., machines in manufacturing facilities or vehicles, machinery, or robots in other settings such as logistics package handling centers) may fail to meet necessary Quality of Service (QoS) guarantees due to slow data access from main memory.

[0268] The various embodiments described below provide technical solutions to one or more of the above technical problems. In one embodiment, the computer system is configured to automatically allocate memory types based on data access patterns.

[0269] In one example, data is initially hosted in an NVRAM device by default (e.g., in the default configuration of an operating system when allocating memory for the startup of a new application installed on a mobile device). If a determined access pattern indicates that the data is frequently used (e.g., read or write accesses more frequently than a predetermined threshold of accesses per given time period), the computer system changes the memory type (e.g., the memory type associated with the data is changed) and moves the data to a DRAM device.

[0270] If the determined access pattern indicates that the data has not been used recently (e.g., the time since last use is greater than a predetermined threshold), the computer system moves the data to a NAND flash device. Optionally, based on the access pattern, the computer system may further pre-move data from a slow memory device to a fast memory device if frequent access (e.g., frequent read or write access by an application determined to be likely to occur in future operation) is anticipated. In one embodiment, based on the access pattern, the system may transfer, move, and / or copy data pre-stored from the slower memory to the faster memory in anticipation of frequent access.

[0271] FIG. 14 illustrates an exemplary computer system (1400) that uses an access table (1404) to map memory access according to some embodiments to different types of physical memory. The computer system (1400) reads and writes data to a memory subsystem (1402). The data is stored in a memory device including a DRAM (304), an NVRAM (306), and a NAND flash (308). In one example, the memory subsystem (1402) provides random access memory for the main memory of a processing device (310).

[0272] In one example, a processing device (310) addresses main memory and accesses data using a memory bus (812) (e.g., the memory bus (812) may include multiple buses such as command and control, address, and data buses). The address space of the main memory includes random access memory (RAM) provided by a physical memory device. The RAM is used to read and write data (e.g., SDRAM). In one example, the RAM is hosted by DRAM (304) and NVRAM (306).

[0273] An operating system (808) runs on a processing device (310) and manages read and write access through a memory bus (812). When data is accessed by a computer system (1400), the operating system (808) maintains the data in an access table (1404). In one example, the maintained data stores characteristics associated with read or write access to the data. In one example, the stored characteristics include data regarding the frequency of access to the stored data.

[0274] In one embodiment, access data stored in the access table (1404) is associated with an application. In one example, data access patterns for the application (1420) (e.g., including access frequency) are stored in the access table (1404). In one example, the data access patterns are associated with the data types used by the application (1420) (e.g., executable code, task data, or memory stack).

[0275] In one embodiment, the cache memory (e.g., SRAM) is located on the same chip (e.g., SoC) as the processing device (310). In one example, the access pattern stores data regarding the use of the cache memory. In one example, the set of memory types further includes one or more cache memory types. In one example, future allocation of specific identified data to the storage of the cache memory is implemented by changing the memory type associated with the data from the currently used memory type (e.g., DRAM) to the cache memory type (e.g., L1, L2, or L3 or other "final level" cache) (e.g., based on data in the access table (1404)).

[0276] In one embodiment, access data regarding read or write access to data stored in the memory subsystem (1402) may be collected as the access operation is performed. For example, access data (1408) may be collected when read or write access to data in the DRAM (304) is performed. In one example, the access data (1408) includes data regarding the operation context of the DRAM (304).

[0277] In one embodiment, the context of the DRAM (304) is represented by sensor data collected by a sensor of the DRAM (304) and / or memory subsystem (1402). In one embodiment, the sensor collects data regarding ambient environmental conditions such as temperature, humidity, electric field and / or magnetic field strength.

[0278] In one embodiment, the access data (1408) includes data regarding the performance and / or reliability of the memory cells of the DRAM (304). In one example, the access data (1408) includes data regarding one or more data of the DRAM (304) or voltage characteristics of another bus, and / or timing data associated with read or write access to the DRAM (304). In one example, the access data (1408) is collected by a controller of the DRAM (304) or another processing device (not shown).

[0279] In one embodiment, access data (1410) is collected for NVRAM (306). Access data (1410) may include data of a similar type to access data (1408). Similarly, access data (1412) is collected for NAND flash (308). In one embodiment, access data (1408, 1410, and / or 1412) is collected by an operating system (808) and stored in an access table (1404).

[0280] In one embodiment, the operating system (808) determines an access pattern for data based on access data (1408, 1410, and / or 1412) without using data from the access table (1404). In response to the determination of the access pattern, the memory type for the data is changed so that the data is stored in one memory device and / or moved from one memory device to another memory device. In one example, the data is moved by the memory management unit (316). In one example, the change in memory type is updated in the page tables (804, 806). In one example, the new memory type is stored in the translation index buffer (810).

[0281] FIG. 15 illustrates an exemplary access table (1500) having records used to map memory access to different types of memory according to some embodiments. The access table (1500) is an example of the access table (1404) of FIG. 14.

[0282] The access table (1500) contains records (1502 and 1504), which are created and updated by the operating system (808) when a read or write access operation is performed. The records (1502, 1504) contain various fields such as a virtual address (1506), a physical address (1508), a memory type (1510), an access pattern (1512), access data (1514), and / or an application or process identifier (1516).

[0283] The virtual address (1506) is a virtual address range corresponding, for example, to the data of the virtual page. In one example, the virtual page is associated with an application (1420). The memory type (1510) is, for example, the type of memory device in which the data for the virtual page is stored. The physical address (1508) is a physical address range in which the data is stored in the memory device.

[0284] In one example, the access pattern (1512) includes data collected regarding various memory access operations associated with data stored at a virtual address (1506). In one example, the access pattern (1512) is the frequency of data access and / or the time since the last access to the data. In one example, the usage data of the entry (902) of the page table (900) corresponds to the access pattern (1512).

[0285] In one example, access data (1514) includes access data received from a memory device in which data corresponding to a virtual address (1506) and / or a physical address (1508) is stored. In one example, access data (1514) includes data from access data (1408, 1410, and / or 1412). In one example, access data (1408, 1410, and / or 1412) is received by a processing device (310) managed by an operating system (808).

[0286] In one embodiment, the identifier (1516) identifies an execution application that uses data stored at a virtual address (1506). In one embodiment, the identifier (1516) identifies one or more processes running on a processing device (310) associated with data accessed at a virtual address (1506) or a physical address (1508). In one example, the process identifier (1516) is stored in an entry of a page table (900) having a virtual address corresponding to the virtual address (1506).

[0287] In one embodiment, the access table (1500) is updated based on data retrieved from metadata (320 and / or 322). In one example, the physical address (1508) is determined using metadata (320, 322) based on the virtual address (1506) as a search input. In one example, the memory type (1510) is determined using metadata (320, 322) based on the virtual address (1506) as an input.

[0288] FIG. 16 illustrates a method for mapping memory access to memory based on access patterns according to some embodiments. For example, the method of FIG. 16 may be implemented in the system of FIG. 14. In one example, the access pattern is stored in an access table (1404).

[0289] The method of FIG. 16 may be performed by processing logic that may include hardware (e.g., a processing device, circuitry, dedicated logic, programmable logic, microcode, hardware of the device, integrated circuit, etc.), software (e.g., instructions performed or executed on the processing device), or a combination thereof. In some embodiments, the method of FIG. 16 is performed at least partially by one or more processing devices (e.g., the processing device (310) of FIG. 14).

[0290] Although illustrated in a specific sequence or order, the order of the processes may be modified unless otherwise specified. Accordingly, the illustrated embodiments should be understood for illustrative purposes only, and the illustrated processes may be performed in a different order, and some processes may be performed in parallel. Additionally, one or more processes may be omitted in various embodiments. Therefore, not all processes are required in all embodiments. Other process flows are possible.

[0291] In block 1601, data is stored in random access memory at one or more logical addresses. The addresses are assigned to applications managed by the operating system, and the data is physically stored in a first memory device. In one example, the logical address represents a virtual address range assigned to the application (1420) by the operating system (808). In one example, the first memory device is NVRAM (306).

[0292] In block 1603, an access pattern for the stored data is determined. In one example, the access pattern is the access pattern (1512) of the access table (1500). In one example, the access pattern indicates that the frequency of access to the data associated with the application (1420) has increased (e.g., exceeding a predetermined threshold). In one example, the access pattern indicates that the priority of the process or application associated with the stored data has increased.

[0293] In block 1605, in response to determining the access pattern, data is moved from the first memory device to a second memory device having a different latency. In one example, data is moved from NVRAM (306) to DRAM (304) having a lower latency.

[0294] In one embodiment, the method comprises the steps of: storing data in one or more first virtual addresses assigned to an application (e.g., application (1420)) running on a computer system by at least one processing device of a computer system (e.g., processing device (310) of FIG. 14)—where the first virtual address corresponds to a first memory device of a first memory type (e.g., NVRAM (306)); determining an access pattern for the stored data (e.g., an access pattern stored in an access table (1404)); and, in response to determining the access pattern, storing data in one or more second virtual addresses assigned to the application—where the second virtual address corresponds to a second memory device of a second memory type (e.g., DRAM (304)).

[0295] In one embodiment, storing data at a second virtual address includes accessing stored metadata (e.g., metadata (320, 322)) that maps the second virtual address to one or more physical addresses of the second memory device.

[0296] In one embodiment, accessing stored metadata includes accessing data from stored metadata cached in a conversion index buffer (e.g., TLB (810)) by a memory management unit (e.g., MMU (316)).

[0297] In one embodiment, the method further includes the step of assigning a second memory type to stored data based on an access pattern.

[0298] In one embodiment, the method further includes the step of determining the physical address of a second memory device where data is stored using an allocated second memory type. In one example, the physical address is determined using stored metadata (320, 322).

[0299] In one embodiment, the step of storing data at a second virtual address includes: changing the memory type of the data from a first memory type to a second memory type; and moving the data from a first memory device to a second memory device in response to the change in memory type. In one example, the data is moved by a memory management unit (316) in response to a change in memory type managed by an operating system (808).

[0300] In one embodiment, moving data from a first memory device to a second memory device includes updating a page table (e.g., page table (804)) to map a second virtual address to one or more physical addresses of the second memory device.

[0301] In one embodiment, determining the access pattern for the stored data includes the step of accessing the usage data of one or more page table entries corresponding to the first virtual address.

[0302] In one embodiment, each page table entry includes a field having a first memory type.

[0303] In one embodiment, determining the access pattern for the stored data includes determining at least one of the usage frequency or the end-use time.

[0304] In one embodiment, storing data at a second virtual address includes changing the namespace bound to the data in the namespace table from a first namespace associated with a first memory type to a second namespace associated with a second memory type.

[0305] In one embodiment, determining the access pattern for stored data includes determining that the frequency of use of the data is greater than a predetermined threshold.

[0306] In one embodiment, the latency of the second memory device is smaller than the latency of the first memory device, and determining the access pattern for the stored data includes determining that the frequency of data usage is greater than a predetermined threshold.

[0307] In one embodiment, the latency of the second memory device is greater than the latency of the first memory device, and determining the access pattern for the stored data includes at least one of determining that the frequency of use of the data is less than a predetermined threshold, or determining that the period after the last use of the data is greater than a predetermined threshold.

[0308] In one embodiment, the latency of the second memory device is smaller than the latency of the first memory device; determining the access pattern for the stored data includes determining that the frequency of future use of the data by the application will be greater than a predetermined threshold; and storing the data at the second virtual address includes moving the stored data from the first memory device to the second memory device by updating a page table that includes one or more virtual pages corresponding to the first virtual address.

[0309] In one embodiment, determining that future usage frequency will be greater than a predetermined threshold includes the step of determining at least one context of an application or computer system; the step of associating the determined context with data regarding the application's historical access pattern; and the step of determining that the historical access pattern corresponds to a usage frequency greater than the predetermined threshold. In one example, the context is determined based on access data (1514) stored in an access table (1500).

[0310] In one embodiment, the system comprises a first memory device of a first memory type; a second memory device of a second memory type; at least one processing device; and a memory containing instructions, wherein the instructions are configured to store data in the random access memory of at least one processing device at one or more logical addresses assigned to an application managed by an operating system (e.g., operating system (808))—data stored in the first memory device—; determine an access pattern for the stored data by the operating system; and, in response to determining the access pattern, instruct to move the data from the first memory device to the second memory device.

[0311] In one embodiment, data is moved from a first memory device to a second memory device by changing the memory type assigned to the data by the operating system.

[0312] In one embodiment, the logical address is the virtual address of one or more virtual pages of the application.

[0313] In one embodiment, a non-transient machine-readable storage medium stores an instruction, and when the instruction is executed on at least one processing device, the at least one processing device causes data to be stored in a random access memory of at least an address range assigned to an application—the address range corresponds to a first memory device of a first memory type—; determine an access pattern for the stored data; and in response to determining the access pattern, cause the data to be moved from the first memory device to a second memory device of a second memory type.

[0314] Conclusion

[0315] The present disclosure includes a data processing system that performs such a method, and a computer-readable medium containing instructions that cause the system to perform such a method when executed on the data processing system, as well as various devices that perform such a method and implement the system described above.

[0316] The description and drawings are exemplary and should not be interpreted as limiting. Many specific details have been described to provide a thorough understanding. However, in certain cases, well-known or common details are omitted to avoid obscuring the description. In this disclosure, the reference to "one" or "one embodiment" does not necessarily refer to the same embodiment; and such reference means at least one.

[0317] References to “one embodiment” or “one embodiment” in this specification mean that specific features, structures, or properties described in connection with one embodiment are included in at least one embodiment of this disclosure. The appearance of the phrase “in one embodiment” at various locations in the specification does not necessarily refer to the same embodiment, nor does it refer to separate or alternative embodiments that are mutually exclusive from other embodiments. Furthermore, various features that may appear in some embodiments and may not appear in others are described. Similarly, various requirements that may be requirements for some embodiments but not for others are described.

[0318] In this description, for the sake of simplicity, various functions and operations may be described as being performed or caused by software code. However, those skilled in the art will recognize that such expression implies that the function is obtained as a result of the execution of code by one or more processors, such as a microprocessor, an Application-Specific Integrated Circuit (ASIC), a graphics processor, and / or a Field-Programmable Gate Array (FPGA). Alternatively, or in combination, functions and operations may be implemented using special-purpose circuitry (e.g., logic circuitry) with or without software instructions. Embodiments may be implemented using hardwired circuitry with or without software instructions. Accordingly, the technology is not limited to any specific combination of hardware circuitry and software, or any specific source of instructions executed by a computing device.

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

[0320] At least some of the disclosed embodiments may be implemented at least partially in software. That is, the technology may be performed on a computing device or other system in response to a processor, such as a microprocessor, executing a sequence of instructions contained in memory, such as ROM, volatile RAM, non-volatile memory, cache, or remote storage device.

[0321] Routines executed to implement the embodiments may be implemented as part of an operating system, middleware, service provider platform, software development kit (SDK) component, web service, or other specific application, component, program, object, module, or instruction sequence referred to as a "computer program." An interface for calling such routines may be exposed to the software development community as an Application Programming Interface (API). A computer program typically consists of one or more instructions set at various times in various memory and storage devices of a computer, and when read and executed by one or more processors of a computer, causes the computer to perform the actions necessary to execute elements involving various modes.

[0322] Machine-readable media can be used to store software and data that enable the device to perform various tasks when executed by a computing device. Executable software and data can be stored in various locations, such as ROM, volatile RAM, non-volatile memory, and / or cache. Parts of this software and / or data may be stored in any of these storage devices. Additionally, data and instructions may be acquired from a centralized server or a peer-to-peer network. Different parts of data and instructions may be acquired from different centralized servers and / or peer-to-peer networks at different times in different communication sessions, or within the same communication session. Data and instructions may be acquired in their entirety prior to application execution. Alternatively, parts of data and instructions may be acquired dynamically and in a timely manner when required for execution. Therefore, data and instructions do not need to be entirely present on the machine-readable medium at a specific time instance.

[0323] Examples of computer-readable media include, but are not limited to, writable and non-writable types of media such as volatile and non-volatile memory devices, read-only memory (ROM), random access memory (RAM), flash memory devices, solid-state drive storage media, removable disks, magnetic disk storage media, and optical storage media (e.g., Compact Disc Read-Only Memory (CD-ROM), Digital Multi-Purpose Disc (DVD), etc.). Computer-readable media can store instructions.

[0324] Generally, a type or non-transient machine-readable medium includes any mechanism that provides (e.g., stores) information in a form accessible by a machine (e.g., a computer, mobile device, network device, personal digital terminal, manufacturing tool, any other device having one or more sets of processors, etc.).

[0325] In various embodiments, hardwired circuits may be used in combination with software and firmware instructions to implement the technology. Accordingly, the technology is not limited to any specific combination of hardware circuits and software or any specific source of instructions executed by a computing device.

[0326] While some drawings illustrate multiple actions in a specific order, actions that do not depend on order may be rearranged, and other actions may be combined or divided. Although some rearrangements or other groupings are specifically mentioned, those skilled in the art will be aware of others, and therefore a complete list of alternatives is not provided. Furthermore, it should be recognized that the stage may be implemented in hardware, firmware, software, or any combination thereof.

[0327] In the specification described above, the present disclosure has been described with reference to specific exemplary embodiments. It will be apparent that various modifications may be made without departing from the broader spirit and scope as described in the claims below. Accordingly, the specification and drawings should be considered in an illustrative sense rather than a restrictive one.

[0328] The various embodiments described in this application may be implemented using a wide variety of different types of computing devices. As used in this application, examples of "computing devices" include, but are not limited to, servers, centralized computing platforms, systems of multiple computing processors and / or components, mobile devices, user terminals, vehicles, personal communication devices, wearable digital devices, electronic kiosks, general-purpose computers, electronic document readers, tablets, laptop computers, smartphones, digital cameras, home appliances, televisions, or digital music players. Additional examples of computing devices include devices that are part of what is referred to as the "Internet of Things (IoT)." These "things" may occasionally interact with their owners or managers who can monitor the things or modify the settings of these things. In some cases, these owners or managers act as users in relation to the "thing" devices. In some examples, the user's primary mobile device (e.g., Apple iPhone) may be a manager server for a paired "thing" device (e.g., Apple Watch) worn by the user.

[0329] In some embodiments, the computing device may be a computer or a host system, which is implemented as, for example, a desktop computer, a laptop computer, a network server, a mobile device, or other computing device including a memory and processing device. The host system may include or be coupled to a memory subsystem so 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 through a physical host interface. Generally, the host system may access multiple memory subsystems through the same communication connection, multiple individual communication connections, and / or a combination of communication connections.

Claims

Claim 1 A method comprising: storing data in one or more first virtual addresses assigned to an application running on the computer system by at least one processing device of the computer system, wherein the first virtual address corresponds to a first memory device of a first memory type; determining an access pattern for the stored data; and, in response to determining the access pattern, storing the data in one or more second virtual addresses assigned to the application, wherein the second virtual address corresponds to a second memory device of a second memory type. Claim 2 The method of claim 1, wherein the step of storing data at the second virtual address comprises the step of accessing stored metadata that maps the second virtual address to one or more physical addresses of the second memory device. Claim 3 A method according to claim 2, wherein the step of accessing the stored metadata comprises the step of accessing the stored metadata cached in a conversion index buffer by a memory management unit. Claim 4 A method according to claim 1, further comprising the step of changing the memory type of the stored data to the second memory type based on the access pattern. Claim 5 A method according to claim 4, further comprising the step of determining the physical address of the second memory device to be stored the data using the modified memory type. Claim 6 A method according to claim 1, wherein the step of storing data at the second virtual address comprises: changing the memory type of the data from the first memory type to the second memory type; and moving the data from the first memory device to the second memory device in response to changing the memory type. Claim 7 A method according to claim 6, wherein the step of moving the data from the first memory device to the second memory device comprises the step of updating a page table to map the second virtual address to one or more physical addresses of the second memory device. Claim 8 A method according to claim 1, wherein the step of determining an access pattern for the stored data comprises the step of accessing usage data of one or more page table entries corresponding to the first virtual address. Claim 9 A method according to claim 8, wherein each of the page table entries comprises a field indicating the first memory type. Claim 10 The method of claim 1, wherein the step of determining an access pattern for the stored data comprises the step of determining at least one of a usage frequency or a final usage time. Claim 11 A method according to claim 1, wherein the step of storing data at the second virtual address comprises changing the namespace bound to the data in a namespace table from the first namespace associated with the first memory type to the second namespace associated with the second memory type. Claim 12 A method according to claim 1, wherein the step of determining an access pattern for the stored data includes the step of determining that the usage frequency of the data is greater than a predetermined threshold. Claim 13 A method according to claim 1, wherein the latency of the second memory device is smaller than the latency of the first memory device, and the step of determining an access pattern for the stored data includes the step of determining that the usage frequency of the data is greater than a predetermined threshold. Claim 14 A method according to claim 1, wherein the latency of the second memory device is greater than the latency of the first memory device, and the step of determining an access pattern for the stored data comprises at least one of the step of determining that the frequency of use of the data is less than a predetermined threshold, or the step of determining that the period after the last use of the data is greater than a predetermined threshold. Claim 15 A method according to claim 1, wherein the latency of the second memory device is smaller than the latency of the first memory device; the step of determining an access pattern for the stored data includes determining that the frequency of future use of the data by the application will be greater than a predetermined threshold; and the step of storing data at the second virtual address includes moving the stored data from the first memory device to the second memory device by updating a page table including one or more virtual pages corresponding to the first virtual address. Claim 16 A method according to claim 15, wherein the step of determining that the future usage frequency will be greater than a predetermined threshold comprises: determining at least one context of the application or the computer system; associating the determined context with data regarding a historical access pattern of the application; and determining that the historical access pattern corresponds to a usage frequency greater than the predetermined threshold. Claim 17 A system comprising: a first memory device of a first memory type; a second memory device of a second memory type; at least one processing device; and a memory containing an instruction, wherein the instruction stores data in the at least one processing device at one or more logical addresses assigned to an application managed by an operating system—the data being stored in the first memory device—; determines an access pattern for the stored data by the operating system; and, in response to determining the access pattern, instructs the system to move the data from the first memory device to the second memory device. Claim 18 A system according to claim 17, wherein the data is moved from the first memory device to the second memory device by changing the memory type assigned to the data by the operating system. Claim 19 A system according to claim 17, wherein the logical address is a virtual address of one or more virtual pages of the application. Claim 20 A non-transient machine-readable storage medium for storing instructions, wherein when the instructions are executed at least one processing device, the at least one processing device stores data in an address range assigned to an application—the address range corresponds to a first memory device of a first memory type—; determines an access pattern for the stored data; and in response to determining the access pattern, moves the data from the first memory device to a second memory device of a second memory type.

Images