Run-time allocation and utilization of persistent memory as volatile memory

Abstract

Embodiments of the present disclosure relate to runtime allocation and utilization of persistent memory as volatile memory. The described techniques enable a computing device to allocate at least a portion of its persistent memory as volatile memory during runtime. At least some implementations create a file in persistent memory of a computing device. A file is created in persistent memory of a computing device during runtime of a virtual machine (VM) hosted by the computing device. The file may be allocated to the VM. The file allocated to the VM may be used as volatile memory. For example, a VM may use a file to store temporary data (e.g., volatile data). In some implementations, the temporary data is associated with an application executing in the VM.

Description

Background Art

[0001] A computing device can host one or more virtual machines (VMs). The host computing device can include a host operating system that manages the resources of the host computing device.

[0002] The resources of the host computing device can include one or more processors and a memory used to store data of the VMs. The memory used to store data of the VMs can be volatile memory or non-volatile memory. Volatile memory is typically used to store temporary data required to support the functions of the VM during the runtime of the VM. The data stored in non-volatile memory (which can also be referred to herein as "persistent memory") is generally available outside the runtime of the VM (such as after the VM is terminated or the host computing device is terminated (e.g., at restart, reboot, or shutdown)).

[0003] Generally, firmware, such as basic input / output system (BIOS) or unified extensible firmware interface (UEFI) firmware, defines the amount of volatile memory and non-volatile memory available to the host computing device and thus available for allocation to VMs. The firmware performs volatile memory and non-volatile memory initialization and instantiation during the boot process (e.g., power-on) of the host computing device.

[0004] The firmware can be configured to change the amount of volatile memory and non-volatile memory available to the host computing device. However, generally, it is necessary to reboot the host computing device to make changes to the configuration of the firmware that defines the amount of volatile memory and non-volatile memory available to the host computing device and shareable with VMs.

[0005] The host computing device typically implements more persistent memory than volatile memory (e.g., terabytes of persistent memory compared to gigabytes of volatile memory). Since the data access performance of persistent memory is approaching the data access performance of volatile memory, the firmware can be configured to allocate some of the persistent memory in the persistent memory as volatile memory available to the host computing device and shareable with VMs.

[0006] As described above, the configuration of the host computer can generally be modified only when the host computing device is booted or rebooted. Therefore, it is impossible to configure persistent memory as volatile memory available to the host computing device during the runtime of the VMs hosted by the host computing device. The present disclosure presented herein is made in view of these and other technical considerations. Summary of the Invention

[0007] A technical solution is disclosed that enables a computing device to allocate at least a portion of persistent memory as volatile memory during the runtime of a VM hosted by the computing device (i.e., the host computing device). There are many technical advantages of the described implementations and technical solutions. Specifically, efficient use of available memory is achieved by the described implementations. For example, the described implementations enable the host computing device to allocate persistent memory as volatile memory during the runtime of the host computing device and the VM hosted by the host computing device. Thus, by using the described implementations and solutions, the current need to reboot the host computing device to access the firmware in order to modify the current allocation of persistent memory and volatile memory is eliminated. Other technical advantages not specifically identified herein may also be achieved by the implementation of the disclosed technology.

[0008] The technical solution disclosed herein includes creating a file, such as a data structure, in the persistent memory of a host computing device. The file can be assigned to a VM hosted by the host computing device. The file assigned to the VM can be used as volatile memory. For example, the VM can use the file to store temporary data (e.g., volatile data) that is needed to support the functions of the VM during its runtime. In some implementations, the temporary data is associated with an application executed in the VM.

[0009] In some implementations, an application executed in the VM generates a memory request, such as a request for volatile memory. The VM can transmit the memory request to the host computing device that hosts the VM. For example, the memory manager of the VM can transmit the memory request to the host computing device. In some implementations, the memory request is received and processed by a hypervisor executed on the host computing device.

[0010] The host computing device can create a file in the persistent memory. The file created in the persistent memory can be assigned or allocated to the VM. In some implementations, the file is used as volatile memory by an application executed in the VM. For example, an application executed in the VM can allocate temporary data, such as data that is typically stored in volatile memory, to the file created in the persistent memory.

[0011] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed implementation. This summary is not intended to identify key or essential features of the claimed subject matter nor is it intended to be used to help determine the scope of the claimed subject matter. For example, the term "technique" may refer to one or more systems, methods, computer-readable instructions, modules, algorithms, hardware logic, and / or operations as permitted by the above context and the entire document. Brief Description of the Drawings

[0012] The detailed implementation manners are described with reference to the accompanying drawings. In the drawings, the leftmost digit(s) of a reference numeral identify the figure in which the reference numeral first appears. The same reference numerals indicate similar or identical items in different figures.

[0013] Figure 1A 、 Figure 1B and Figure 2 are block diagrams of computing devices that implement virtual machines (VMs) and that can be used with one or more of the described implementations.

[0014] Figure 3 and Figure 4 are block diagrams of computing devices that implement containers and that can be used with one or more of the described implementations.

[0015] Figure 5 and Figure 6 are block diagrams of several computing devices that are configured to create files in persistent memory and that can be used with one or more of the described implementations.

[0016] Figure 7 is a flowchart that illustrates aspects of a routine for creating a file in persistent memory for use as volatile memory, in accordance with one exemplary embodiment, as disclosed herein.

[0017] Figure 8 is a flowchart that illustrates aspects of a routine for creating a file in persistent memory for use as volatile memory, in accordance with one exemplary embodiment, as disclosed herein.

[0018] Figure 9 is a computer architecture diagram that illustrates an illustrative computer hardware and software architecture for a computing device that can implement aspects of the techniques presented herein.

[0019] Figure 10 is a network diagram that depicts a distributed computing environment in which aspects of the disclosed techniques can be implemented. Detailed Implementation Manners

[0020] Traditional computing devices allocate volatile memory and non-volatile memory or persistent memory when booting (such as when they are powered on or rebooted). A technical solution is provided such that a computing device can allocate at least a portion of persistent memory as volatile memory during the runtime of the computing device. The disclosed technical solution also enables a computing device to allocate at least a portion of persistent memory as volatile memory during the runtime of a virtual machine (VM).

[0021] The technical solutions presented in this document include creating a file in the persistent memory of a computing device. The file can be assigned to a VM hosted by the computing device. The file assigned to the VM can be used as volatile memory. For example, the VM can use the file to store temporary data (such as volatile data) that is required to support the functionality of the VM during its runtime. In some implementations, the temporary data is associated with an application executed in the VM.

[0022] There are many technical advantages to the described implementations and technical solutions. Specifically, the efficient use of available memory is achieved by the described implementations. For example, the described implementations enable the host computing device to allocate persistent memory as volatile memory during the runtime of the host computing device and during the runtime of the VMs hosted by the host computing device. Thus, by using the described implementations and solutions, the following traditional requirement is eliminated: the host computing device must be rebooted to access the firmware to modify the current allocation of persistent memory and volatile memory.

[0023] This disclosure describes requests, instructions, and other communications that are transmitted to various elements associated with one or more computing devices. The disclosed requests, instructions, and other communications include data that transmits or defines an action to be performed, or the information conveyed by these requests, instructions, and other communications. Additionally, the requests, instructions, and other communications described herein can be generated by instructions executed by one or more processors of one or more computing devices. For example, the instructions can be associated with one or more application programming interfaces (APIs) executed by one or more processors of one or more computing devices.

[0024] Figure 1A A high-level block diagram of a computing device 102 is illustrated, which can be used with one or more of the described implementations. The computing device 102, also referred to herein as the host computing device 102, can host one or more VMs. In the illustrated example, the host computing device 102 hosts VM 104 and VM 106.

[0025] Generally, the host computing device 102 is one or more data processing devices, such as a rack-mounted server or other computing device. The host computing device 102 may be located at a single physical location or distributed across different physical locations. The host computing device 102 can have different capabilities and computer architectures.

[0026] The host computing device 102 can communicate with other computing devices via a local data communication network (not shown). For example, the local data communication network can include one or more wired networks (such as Ethernet) or wireless networks (such as Wi-Fi). The host computing device 102 can also communicate with other computing devices on an external network (such as the Internet) via one or more gateways, which are responsible for routing data communication traffic between the local data communication network and the external network.

[0027] The host computing device 102 can execute a host operating system (OS) 108. The host OS 108 can manage the resources of the host computing device 102. In some implementations, the host OS 108 executes software, such as a hypervisor 110 or other type of virtual machine monitor (VMM), which virtualizes the hardware of the host computing device 102. In some implementations, the hardware virtualized by the hypervisor 110 includes one or more processors 112, persistent memory 114, volatile memory 116, and / or network interface controller (NIC) 118. The hypervisor 110 can virtualize other hardware of the host computing device 102.

[0028] In some implementations, the hypervisor 110 manages the parallel execution of one or more VMs (such as VM 104 and VM 106). Each of the VMs 104 and 106 provides a virtual instance of the physical hardware (such as processors 112, persistent memory 114, and volatile memory 116), which may (but need not) be based on the host computing device 102 and the hardware architecture of the host computing device 102. The virtualized instances of the physical hardware associated with the host computing device 102 can be referred to herein as "virtual hardware". For example, VM 104 includes virtual memory 120, and VM 106 includes virtual memory 122. As described above, VMs 104 and 106 can also utilize virtualized processors and NICs.

[0029] In some implementations, the virtual memory 120 is implemented by the hypervisor 110. For example, the hypervisor 110 can interface with a memory manager 124 to implement the virtual memory 120. In some implementations, the hypervisor 110 and the memory manager 124 implement the virtual memory 120 in various ways, such as by mapping the pages of the virtual memory 120 to the pages of the volatile memory 116. The hypervisor 110 and the memory manager 124 can also map the virtual bits or blocks of the virtual memory 120 to the physical bits or blocks of the persistent memory 114. The physical bits or blocks of the persistent memory 114 can store data structures, such as one or more files. The virtual memory 122 can be implemented in the same manner as described for the virtual memory 120.

[0030] In some examples, persistent memory 114 is implemented using memory devices, which may include various types of non-volatile memory. Non-volatile memory may include, but is not limited to, non-volatile types of memory that may be bit, byte, or block addressable. These bit-addressable, block-addressable, or byte-addressable non-volatile types of memory may include, but are not limited to, non-volatile random access memory (NVRAM), NAND flash memory, NOR flash memory, single-level or multi-level phase change memory (PCM), resistive memory, magnetoresistive random access memory (MRAM) memory, 3D XPoint non-volatile memory in a dual in-line memory module (DIMM) or solid-state device (SSD) form factor, or other non-volatile memory types.

[0031] Persistent memory 114 may be disposed in one or more non-uniform memory access (NUMA) nodes 126. Each of NUMA nodes 126 may include an associated processor (e.g., processor 112), volatile memory (e.g., volatile memory 116), and persistent memory 114. Persistent memory 114 may have a DIMM form factor that is coupled to NUMA nodes 126 of host computing device 102. Alternatively, persistent memory 114 may have an SSD form factor. Persistent memory 114 may have other form factors.

[0032] In addition, in some examples, the volatile memory 116 can be composed of one or more memory devices, which can include various types of volatile memory. Volatile memory can include, but is not limited to, random access memory (RAM), dynamic RAM (DRAM), double data rate synchronous dynamic RAM (DDR SDRAM) or static random access memory (SRAM) or other types of volatile memory types.

[0033] VM 104 may include OS 128 and one or more applications 130, also referred to herein as VM applications 130. OS 128 may control the execution of applications 130 within VM 104 and provide services for VM 104. In some implementations, OS 128 includes a memory manager 150. Memory manager 150 may receive and process allocation requests from one or more applications 130. Memory manager 150 may also reside outside of OS 128. OS 128 may be a version of the WINDOWS operating system from Microsoft Corporation or another type of operating system. OS 128 may be implemented by other operating systems. In some implementations, VM 104 does not require an OS implementation. Such an implementation may be performed in a manner similar to that described in the accompanying drawings. Figure 3 , Figure 4 and Figure 6 is shown in the figure.

[0034] OS 128 can manage access to the virtual memory 120 on behalf of the application 130. In other implementations, the application 130 can directly access the virtual memory 120.

[0035] In some implementations, with reference to VM 104, when the application 130 or the OS 128 attempts to perform an I / O operation on the virtual memory 120, initiate network communication, or perform another operation, the hypervisor 110 can be interrupted so that the host OS 108 can perform operations in cooperation with the hypervisor 110 and the memory manager 124 on behalf of the VM 104. The host OS 108 is capable of performing operations on behalf of the VM 104 by executing operations in the kernel process space, user process space, or both (not shown) of the host computing device 102.

[0036] Similarly, the VM 106 can include an OS 132 and one or more applications 134. The functionality of the VM 106 and its underlying elements can be the same as or similar to those described with respect to the VM 104.

[0037] The functionality of the host computing device 102 for allocating the persistent memory 114 to be used as volatile memory is described below. The functionality for allocating the persistent memory 114 to be used as volatile memory will be described with reference to the VM 104. Similar functionality can be performed by the VM 106.

[0038] In some implementations, the host OS 108, the hypervisor 110, and / or the memory manager 124 allocate some portions of the persistent memory 114 and some portions of the volatile memory 116 to the volatile memory 116. Conventionally, the amounts of the persistent memory 114 and the volatile memory 116 are established by the firmware of the host computing device 102. As described above, modifying the allocation of the persistent memory 114 and the volatile memory 116 conventionally requires using a reboot process or simply a boot process to restart the host computing device 102. However, it may be impossible or impractical to reboot the host computing device 102 during the active runtime instantiation of the VM 104 and / or the VM 106.

[0039] The described implementations provide techniques that allow some or all of persistent memory 114 to be allocated for use as non-volatile memory without the traditional requirement of rebooting or booting host computing device 102. To enable runtime allocation of persistent memory 114 for use as volatile memory, some of the implementations described herein introduce the generation of one or more files 136 (e.g., at least one data structure or memory allocation) in persistent memory 114. In some implementations, a memory address range, whether contiguous or non-contiguous, is defined in persistent memory 136. The memory address range in persistent memory 136 can be used as volatile memory.

[0040] File 136 can be allocated to virtual memory 120 of virtual machine 104. Specifically, file 136 can be allocated to virtual memory 120 and used as volatile memory by application 130 and / or OS 128. Specifically, file 136 can be used to store temporary data, such as volatile data, that would typically be stored in a portion of volatile memory 116 allocated to virtual memory 120.

[0041] Application 130 can generate a memory request. The memory request can be provided to OS 128 for forwarding to host OS 108. Alternatively, application 130 can transmit the memory request directly to host OS 108. For example, application 152 can generate a memory request for direct transmission to host OS 108. In some implementations, application 152 is a VM application. In another example, the memory request can be generated by OS 128 on behalf of application 130, or OS 128 can automatically generate a memory request.

[0042] In response to a memory request from VM 104, host computing device 102, host OS 108, or hypervisor 110 can generate a memory allocation request that can include a request for volatile memory. In some implementations, the memory allocation request can include, in data form, a request for an allocation of persistent memory 114 that will be used as volatile memory by one or more of application 130 or 152 and OS 128.

[0043] A memory allocation request may include, but is not limited to, data that specifies: (1) the amount of memory requested (e.g., in bytes); (2) whether the amount of memory requested will be persistent, such as when the host computing device 102 is powered off or rebooted; (3) whether the amount of memory requested is to be encrypted; (4) whether the amount of memory requested will consume a contiguous portion of the persistent memory 114; (5) whether the amount of memory requested is to be implemented as a large page, super page, huge page, or gigantic page; and / or (6) whether the amount of memory requested will be implemented using persistent memory in a particular one or more NUMA nodes, where the one or more NUMA nodes are identified by corresponding one or more NUMA node identifiers.

[0044] The memory manager 124 may process the memory allocation request. In some implementations, as described above, the hypervisor 110 may receive a memory request from the VM 104 or the application 152 and forward the memory request to the OS 108 and / or the memory manager 124.

[0045] The memory manager 124 receives the memory allocation request and evaluates its data and content to determine the parameters included in the memory allocation request. Based on a policy that controls the use of memory and the evaluation of the memory allocation request, the memory manager 124 generates a create file instruction for transmission to the persistent memory 114.

[0046] The create file instruction is provided to the persistent memory 114, and the create file instruction includes data to cause a file 136 to be generated based on the parameter details of the memory allocation request, according to the parameters described and encapsulated therein. In some implementations, the memory manager 124 interfaces with the file system of the host computing device 102 and / or the host OS 108 to create the file 136.

[0047] Figure 1B A high-level block diagram illustrates a computing device 102 and various request flows that may be used with one or more of the described implementations. The application 130 may generate a memory request. The memory request may be provided to the OS 128 and the memory manager 150 for forwarding to the host OS 108 or the hypervisor 110. Alternatively, the application 130 may transmit the memory request directly to the host OS 108. For example, the application 152 may generate a memory request for direct transmission to the host OS 108. In some implementations, the application 152 is a VM application, such as the VM machine 104. In another example, the memory request may be generated by the OS 128 on behalf of the application 130, or the OS 128 may autonomously generate a memory request.

[0048] In response to a memory request from VM 104, host computing device 102, host OS 108, or hypervisor 110 may generate a memory allocation request 138, which may include a request for volatile memory. In some implementations, memory allocation request 138 may include, by way of data, a request for the allocation of persistent memory 114, which will be used as volatile memory by one or more of applications 130 or 152 and OS 128.

[0049] Memory allocation request 138 may include, but is not limited to, data that specifies: (1) the amount of memory requested (e.g., in bytes); (2) whether the amount of memory requested will be persistent, such as when host computing device 102 is shut down or rebooted; (3) whether the amount of memory requested is to be encrypted; (4) whether the amount of memory requested will consume a contiguous portion of persistent memory 114; (5) whether the amount of memory requested is to be implemented as a large page, super page, huge page, or gigantic page; and / or (6) whether the amount of memory requested is to be implemented using persistent memory in a particular one or more NUMA nodes, where the one or more NUMA nodes are identified by corresponding one or more NUMA node identifiers.

[0050] Memory manager 124 may process memory allocation request 138. In some implementations, as described above, hypervisor 110 may receive a memory request from VM 104 or application 152 and forward the memory request to OS 108 and / or memory manager 124.

[0051] Memory manager 124 receives the memory allocation request and evaluates its data and content to determine the parameters included in memory allocation request 138. Based on a policy that controls the use of memory and the evaluation of memory allocation request 138, memory manager 124 generates a create file instruction 140 for transmission to persistent memory 114.

[0052] Create file instruction 140 is provided to persistent memory 114, and create file instruction 140 includes data to cause a file 136 to be generated based on the parameter details of memory allocation request 138, according to the parameters described and encapsulated in create file instruction 140. In some implementations, create file instruction 140 is provided to persistent memory 114 via hypervisor 110. In some implementations, memory manager 124 interfaces with the file system of host computing device 102 and / or host OS 108 to create file 136.

[0053] Now referring to Figure 2 , in the case of create file instruction 140 (as Figure 1BAfter being forwarded to the persistent memory 114 as shown, the memory manager 124 generates a file creation confirmation 142, which is forwarded to the OS 128 and / or the memory manager 150. As illustrated, the hypervisor 110 may receive the file confirmation 142 and forward the confirmation 142 to the OS 128 and / or the memory manager 150.

[0054] The file creation confirmation 142 may include data identifying the corresponding memory allocation request 138 so that the OS 128, the hypervisor 110, and / or the memory manager 150 can appropriately allocate the file 136 to the requesting application 130 or the OS 128 for its use.

[0055] In addition, the OS 128, the hypervisor 110, and / or the memory manager 150 allocate the file 136 to the virtual memory 120 by way of an allocation file instruction 144. Specifically, once the file 136 is allocated to the virtual memory 120, the requesting application 130 or the OS 128 can access the file 136, which is allocated to the virtual memory 120 to be used as a volatile memory for storing temporary data (such as data that is typically stored in the virtualized portion of the volatile memory 116).

[0056] Figure 3 An advanced block diagram of a computing device 202 that can be used with one or more of the described implementations is illustrated. The computing device 202, also referred to herein as the host computing device 202, can host one or more containers. In the illustrated example, the host computing device 202 is hosting the container 204 and the container 206. The containers 204 and 206 can also be regarded as memory partitions or memory resources associated with the host computing device 202.

[0057] The containers 204 and 206 operate similarly to Figure 1A 、 Figure 1B and Figure 2 the VMs 104 and 106 shown in. The main differences between the containers 204 and 206 and the VMs 104 and 106 are that the containers 204 and 206 do not implement an OS. In addition, the containers 204 and 206 do not include virtualized hardware, such as the virtual memories 120 and 122. Instead, each of the containers 204 and 206 shares the host OS 108 of the host computing device 202 and the associated hardware. The host OS 108 and the container manager 208 cooperate to arbitrate the sharing of the host OS 108 of the host computing device 202 and the associated hardware between the containers 204 and 206. In some implementations, the container manager 208 can be a hypervisor, such as Figure 1A 、 Figure 1B and Figure 2 the hypervisor 110 shown in.

[0058] Typically, the host computing device 202 is one or more data processing devices, such as rack-mounted servers or other computing devices. Multiple host computing devices 202 may be located in a single physical location or distributed across different physical locations. The host computing devices 202 may have different capabilities and computer architectures.

[0059] The host computing devices 202 may communicate with each other via an internal data communication network (not shown). For example, the internal data communication network may include one or more wired networks (e.g., Ethernet) or wireless networks (e.g., Wi-Fi). In some implementations, the internal data communication network is an intranet.

[0060] The host computing devices 202 may also communicate with devices on an external network (such as the Internet) via one or more gateways, which are data processing devices responsible for routing data communication traffic between the internal data communication network and the external network.

[0061] In some implementations, the container manager 208 manages the parallel execution of one or more containers (such as containers 204 and 206). The container manager 208 provides a physical hardware system (e.g., processor 112, persistent memory 114, and volatile memory 116) to the containers 204 and 206, which may (but need not) be based on the host computing device 202 and the hardware architecture of the host computing device 202.

[0062] In some implementations, the container manager 208 may interface with the memory manager 124 to allocate memory (such as persistent memory 114 and volatile memory 116) to the containers 204 and / or 206. In other implementations, the container manager 208 may allocate memory by performing the functions described with reference to the memory manager 124.

[0063] In some implementations, the container manager 208 and the memory manager 124 allocate memory in various ways, such as by assigning memory pages of the volatile memory 116 to one or more of the containers 204 and 206. Moreover, the container manager 208 and the memory manager 124 may map physical bits or blocks of the persistent memory 114 to one or more of the containers 204 and 206. At least a plurality of physical bits or blocks of the persistent memory 114 may be used to store one or more files, such as one or more data structures. In other implementations, the container 204 interfaces directly with the host OS 108 and / or the memory manager 124 for memory allocation.

[0064] The function of the host computing device 202 for allocating persistent memory 114 to be used as volatile memory is described below. The function for allocating persistent memory 114 to be used as volatile memory will be described with reference to container 204. Similar functions may be performed by container 206 or other applications executing in the host computing device 202.

[0065] In some implementations, container 204 is allocated some portions of persistent memory 114 and some portions of volatile memory 116 by the host OS 108 and its container manager 208 and memory manager 124.

[0066] To enable runtime allocation of persistent memory 114 to be used as volatile memory, some of the implementations described herein introduce generating files in persistent memory 114, such as one or more files 136 (e.g., one or more data structures or memory allocations), for use by container 204. File 136 may be allocated to container 204. Specifically, file 136 may be allocated to container 204 and used by application 130 as volatile memory. Specifically, file 136 may be used to store temporary data, such as volatile data, which would typically be stored in the portion of volatile memory 116 allocated to container 204.

[0067] Application 130 or container 204 may generate a memory request. The memory request may be provided to the host OS 108 via container manager 208 or provided directly to the host OS 108. The memory request may include a request for volatile memory. As previously described, memory manager 124, host OS 108, and / or container manager 208 may include policies that control the use of volatile memory 116 and persistent memory 114.

[0068] Container manager 208 or host OS 108 may generate a memory allocation request 138. The memory allocation request 138 may be transmitted to memory manager 124.

[0069] The memory allocation request 138 may specify parameters that define: (1) the amount of memory requested (e.g., in bytes); (2) whether the amount of memory requested will be persistent, such as after the host computing device 202 is powered off or rebooted; (3) whether the amount of memory requested is to be encrypted; (4) whether the amount of memory requested is to consume a contiguous portion of persistent memory 114; (5) whether the amount of memory requested is to be implemented as a large page, super page, huge page, or gigantic page; and / or (6) whether the amount of memory requested is to be implemented using persistent memory in a particular one or more NUMA nodes, where the one or more NUMA nodes are identified by corresponding one or more NUMA node identifiers.

[0070] The memory manager 124 receives a memory allocation request 138 and identifies the parameters contained therein. The memory manager 124 then uses the policy and parameters for memory usage to generate a create file instruction 140 for transmission to the persistent memory 114.

[0071] The create file instruction 140 is provided to the persistent memory 114 so that, based on the parameter details of the memory allocation request 138, a file 136 is generated according to the parameters described and encapsulated in the create file instruction 140. In some implementations, the memory manager 124 interfaces with the file system of the host computing device 102 and / or the host OS 108 to create the file 136.

[0072] Now referring Figure 4 , after forwarding the create file instruction 140 to the persistent memory 114, the memory manager 124 generates a file creation confirmation 142 that is forwarded to the container manager 208. Alternatively, the host OS 108 or the memory manager 124 can forward the file creation confirmation 142 to the container 204 or the application 130. The file creation confirmation 142 can include data such as a reference to the memory allocation request 138 and / or the memory request so that the requesting application 130 can appropriately access the file 136. The requesting application 130 can access the file 136 that is allocated to the requesting application 130 and serves as volatile memory for storing temporary data (such as data that is typically stored in the volatile memory 116).

[0073] Figure 5 Illustrated are actions performed by the host computing device 102 to modify a file 136 that is created in the persistent memory 114 by a VM (such as VM 104) hosted by the host computing device 102 to serve as volatile memory.

[0074] The application 130, VM 104, and / or application 152 can request volatile memory. In some implementations, the memory manager 150 receives a request for volatile memory and forwards the request to the hypervisor 110 or the host OS 108. Alternatively, the request can be transmitted directly to the host OS 108.

[0075] A modify file instruction 504 can be generated by the memory manager 124. The memory manager 124 can generate the modify file instruction 504 in response to a request for volatile memory from the VM 104, application 130, application 152, and / or hypervisor 110. In some implementations, the memory manager 124 interfaces with the file system of the host OS 108 to generate the modify file instruction 504.

[0076] The modify file instruction 504 can include a parameter that indicates whether the request is: (1) a request to expand or shrink the amount of memory (e.g., in bytes) associated with file 136, (2) a request to delete file 136, (3) a request to encrypt file 136, (4) a request to move file 136 to a contiguous portion of persistent memory 114, (5) a request to implement file 136 using large pages, superpages, huge pages, or gigantic pages, (6) a request to implement file 136 in persistent memory associated with a particular one or more NUMA nodes, and / or (7) a request to modify the persistence attributes associated with file 136.

[0077] The modify file instruction 504 is provided to persistent memory 114. The instruction 504 causes file 136 to be modified according to data that defines the parameter described in the modify file instruction 504, which parameter is encapsulated therein based on the parameter details of the file modification request 502.

[0078] Figure 6 Illustrated are actions performed by host computing device 202 to modify file 136, which file 136 is created in persistent memory 114 by a container (such as container 204) hosted by host computing device 202 and used as volatile memory. Specifically, application 130, application 152, and / or container 204 can generate requests for virtual memory. The requests can be transmitted to container manager 208 and thereby relayed to host OS 108. Alternatively, host OS 108 can directly receive the requests.

[0079] The modify file instruction 604 can be generated by memory manager 124. Memory manager 124 can generate the modify file instruction 604 in response to a volatile memory request from container 204, application 130, application 152, and / or hypervisor 208. In some implementations, memory manager 124 interfaces with the file system of host OS 108 to generate the modify file instruction 604.

[0080] The modify file instruction 604 may use the data and indicators of the modify file instruction 604 to specify: (1) a request to expand or shrink the amount of memory (e.g., in bytes) associated with file 136, (2) a request to delete file 136, (3) a request to encrypt file 136, (4) a request to move file 136 to a contiguous portion of persistent memory 114, (5) a request to implement file 136 using large pages, superpages, huge pages, or gigantic pages, (6) a request to implement file 136 in persistent memory associated with a particular one or more NUMA nodes, and / or (7) a request to modify the persistence attributes associated with file 136.

[0081] The modify file instruction 604 is provided to persistent memory 114. Instruction 604 causes file 136 to be modified according to the data that defines the parameters described in the modify file instruction 604.

[0082] Figure 7 is a flowchart that illustrates aspects of a routine 700 for creating a file in persistent memory for use as volatile memory as disclosed herein according to one exemplary embodiment. In some implementations, Figure 7 the operations shown therein may be performed by components of one or more computing devices, such as one or more of devices 102 and 202. Accordingly, the instructions associated with routine 700 may be executed by one or more processors associated with devices 102 and 202.

[0083] Those of ordinary skill in the art will appreciate that the operations of the methods disclosed herein are not necessarily presented in any particular order, and that some or all of the operations may be performed in (a) alternative order(s) and are contemplated. For ease of description and illustration, the operations have been presented in a demonstration order. Operations may be added, omitted, performed together, and / or performed simultaneously without departing from the scope of the appended claims.

[0084] It should also be understood that the methods shown may end at any time and need not be executed in their entirety. Some or all of the operations of the methods and / or substantially equivalent operations may be performed by executing computer-readable instructions included on a computer storage medium. The term "computer-readable instructions" and its variants, as used in the specification and claims, are used herein broadly to include routines, applications, application modules, program modules, programs, components, data structures, algorithms, etc. Computer-readable instructions may be implemented on a variety of system configurations, including single-processor or multi-processor systems, minicomputers, mainframe computers, personal computers, handheld computing devices, microprocessor-based programmable consumer electronics, combinations thereof, and the like.

[0085] Accordingly, it should be recognized that the logical operations described herein are implemented as (1) a sequence of computer-implemented acts or program modules running on a computing system (e.g., (one or more) devices 102 and / or 202), and / or (2) interconnected machine logic circuits or circuit modules within the computing system. The implementation is a matter of choice depending on the performance and other requirements of the computing system. Thus, the logical operations may be implemented in software, firmware, dedicated digital logic, and any combination thereof. In addition, the logical operations described herein may be implemented by a single computing device such as a client device or a server device. Alternatively, the logical operations described herein may be implemented by a combination of a server device and a client device.

[0086] Routine 700 may begin at operation 702, where a memory allocation request is received. The memory allocation request may include data that identifies the amount of persistent memory to be allocated as volatile memory for use by a VM (VM application or application). During the runtime of the host computing device, the memory allocation request may be received and associated with the host computing device. For example, the memory allocation request 138 may be received by the host computing device 102 or the host computing device 202. The memory allocation request 138 may be generated by the VM 104, the VM application 130, the application 152, or the container 204 in response to a memory request.

[0087] At operation 704, a file is created in the persistent memory for use by the VM application or application. In some implementations, the file 136 is created in the persistent memory 114, which is associated with the host computing device 102 or the host computing device 202.

[0088] At operation 706, the file created in the persistent memory is allocated to the VM application or application. In some implementations, the file 136 created in the persistent memory is allocated to the VM 104, the application 152, the VM application 130, or the OS 128 of the host computing device 102 of the container 204 and / or the application 130 or the application 152 of the container 204. Allocating the file to the VM application or application may include identifying the addressing and length of the file allocated to the VM application or application.

[0089] At operation 708, a file creation confirmation message is sent to the VM application or application. The file creation confirmation message may include data that identifies the file in the persistent memory for use by the VM application or application as volatile memory. For example, the file creation confirmation message 142 may be passed to the VM 104, the application 152, the VM application 130, or the container 204.

[0090] At operation 710, the VM application or application begins using the file as volatile memory. For example, the VM application 130, application 152, or OS 128 of the host computing device 102 or the container 204 and / or the application 130 of the container 204 may use the file 136 as volatile memory.

[0091] In some implementations, one or more of operations 702 to 708 are performed as background processes isolated or hidden from the user. Specifically, operations 702 to 708 may be performed by an operating system, such as the MICROSOFT WINDOWS operating system, software applications, etc., on background execution threads.

[0092] Figure 8 is a flowchart that illustrates aspects of an example routine 800 disclosed herein for creating a file in persistent memory to be used as volatile memory. In some implementations, Figure 8 the operations shown therein may be performed by components of one or more computing devices, such as one or more of devices 102 and / or 202. Accordingly, the instructions associated with example routine 800 may be executed by one or more processors associated with devices 102 and / or 202.

[0093] When a memory request is generated at the VM application, VM, or application, routine 800 may begin at operation 802. The memory request may include data that identifies a request for volatile memory to be used by the VM application, VM, or application. In some implementations, the memory request is generated by the VM 104, application 130, application 152, or container 204.

[0094] At operation 804, the memory request is transmitted to the host computing device. The host computing device may manage the memory allocation for the VM application, VM, or application. In some implementations, the memory request is transmitted to an element of the host computing device 102 or host computing device 202. For example, in some implementations, the memory request may be received by the host OS 108 of the host computing device 102 or the host OS 108 of the host computing device 202.

[0095] At operation 806, a file creation confirmation message is received at the VM application, VM, or application. In some implementations, the hypervisor (which is also an application) receives the confirmation message. For example, the file creation confirmation message 142 may be generated by the host OS 108 of the host computing device 102 or the host computing device 202. In some implementations, the file confirmation message 142 includes data that identifies the file 136 created in the persistent memory 114.

[0096] In some implementations, one or more of operations 802 to 806 are performed using a background execution thread. Specifically, operations 802 to 806 may be performed by a background thread that is executed by an operating system (such as the MICROSOFT WINDOWS operating system, software applications, etc.).

[0097] Figure 9 is a computer architecture diagram that shows an illustrative computer hardware and software architecture of a computing device 900, which may implement aspects of the techniques presented herein. Specifically, Figure 9 the architecture shown in may be used to implement a server computer, mobile phone, e-reader, smartphone, desktop computer, AR / VR device, tablet computer, laptop computer, or another type of computing device. In some implementations, devices 102 and 202 implement some or all of the elements and functionality associated with computing device 900.

[0098] Figure 9 The computer 900 shown in includes: a central processing unit 902 (CPU); a system memory 904 including a random access memory 906 (RAM) and a read-only memory (ROM) 908; and a system bus 910 that couples the memory 904 to the CPU 902. The basic input / output system (BIOS or firmware), containing basic routines that help transfer information between elements in the computer 900, such as during startup, may be stored in the ROM 908. The computer 900 also includes a mass storage device 912 for storing an operating system 922, application programs, and other types of programs. The mass storage device 912 may also be configured to store other types of programs and data.

[0099] The mass storage device 912 is connected to the CPU 902 via a mass storage controller ( Figure 9 not shown in), which is connected to the bus 910. The mass storage device 912 and its associated computer-readable medium provide non-volatile storage for the computer 900. Although the description of computer-readable media included herein refers to mass storage devices such as hard disks, CD-ROM drives, DVD-ROM drives, or USB storage keys, those skilled in the art should recognize that computer-readable media can be any available computer storage medium or communication medium that can be accessed by the computer 900.

[0100] A communication medium includes computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transmission mechanism, and includes any delivery medium. The term "modulated data signal" refers to a signal having one or more of its characteristics set or changed in some manner to encode information in the signal. By way of example, and not limitation, communication media include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Combinations of any of the above should also be included within the scope of computer-readable media.

[0101] By way of example, and not limitation, computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. By way of example, and not limitation, computer storage media include, but are not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid state storage technology, CD-ROM, digital versatile disks (DVD), HD-DVD, Blu-Ray or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by a computer 900. For purposes of the claims, the phrase "computer storage media" and variations thereof do not include waves or signals per se or a communication medium.

[0102] In accordance with various configurations, computer 900 may operate in a network environment using a logical connection to a remote computer through a network such as network 920. Computer 900 may be connected to network 920 through network interface unit 916, which is connected to bus 910. It should be appreciated that network interface unit 916 may also be used to connect to any type of network and remote computer systems. Computer 900 may also include an input / output controller 918 for receiving and processing input from a number of other devices, including a keyboard, mouse, touch input, electronic pen ( Figure 9 not shown in the figure) or a physical sensor such as a camera. Similarly, input / output controller 918 may provide output to a display screen or other type of output device ( Figure 9 not shown in the figure).

[0103] It should be appreciated that the software components described herein, when loaded into and executed by the CPU 902, can transform the CPU 902 and the entire computer 900 from a general-purpose computing device into a special-purpose computing device that is customized to support the functionality presented herein. The CPU 902 is constructed from any number of transistors or other discrete circuit elements that can individually or jointly assume any number of states. More specifically, the CPU 902 can operate as a finite state machine in response to the executable instructions contained in the software modules disclosed herein. These computer-executable instructions can transform the CPU 902 by specifying how the CPU 902 transitions between states, thereby transforming the transistors or other discrete hardware elements that make up the CPU 902.

[0104] Encoding the software modules presented herein can also transform the physical structure of the computer-readable medium presented herein. In the different implementations of this description, the specific transformation of the physical structure depends on various factors. Examples of these factors include, but are not limited to, the technology used to implement the computer-readable medium, whether the computer-readable medium is characterized as a main storage device or an auxiliary storage device, and so on. For example, if the computer-readable medium is implemented as a semiconductor-based memory, the software disclosed herein can be encoded on the computer-readable medium by transforming the physical states of the semiconductor memory. For example, the software can transform the states of the transistors, capacitors, or other discrete circuit elements that make up the semiconductor memory. The software can also transform the physical states of such components to store data thereon.

[0105] As another example, the computer-readable medium disclosed herein can be implemented using magnetic or optical technologies. In such an implementation, the software presented herein can transform the physical states when encoded in the magnetic or optical medium. These transformations can include changing the magnetic properties of specific locations in a given magnetic medium. These transformations can also include changing the physical characteristics or properties of specific locations in a given optical medium to alter the optical properties of those locations. Other transformations of the physical medium are possible without departing from the scope and spirit of this specification, and the foregoing examples are provided only for the sake of facilitating such discussion.

[0106] In view of the foregoing, it should be appreciated that many types of physical transformations occur in the computer 900 in order to store and execute the software components presented herein. It should also be appreciated that Figure 9The architecture of computer 900 shown, or a similar architecture, can be used to implement other types of computing devices, including handheld computers, video game devices, embedded computer systems, mobile devices (such as smart phones, tablet computers, and AR / VR devices), and other types of computing devices known to those skilled in the art. It is also contemplated that computer 900 may not include Figure 9 all of the components shown in Figure 9 and may include other components not explicitly shown in Figure 9 or may utilize a completely different architecture than that shown in

[0107] Figure 10 is a network diagram illustrating a distributed network computing environment 1000 according to various embodiments presented herein, in which aspects of the disclosed technology may be implemented. Computing device 102 and / or 202 may implement the distributed network computing environment 1000 to provide distributed storage via one or more distributed physical or virtual storage devices associated with one or more computing devices.

[0108] As Figure 10 shown in

[0109] one or more server computers 1000A may be interconnected via a communication network 920 (which may be a fixed wired or wireless LAN, WAN, intranet, extranet, peer-to-peer network, virtual private network, the Internet, a Bluetooth communication network, a dedicated low-voltage communication network, or other communication network), the communication network 920 having a number of devices such as, but not limited to, tablet computer 1000B, game console 1000C, smartwatch 1000D, telephone 1000E (such as a smart phone), personal computer 1000F, and AR / VR device 1000G. Figure 10 not shown in Figure 10 or other graphical user interface Figure 10 not shown in

[0110] Server computer 1000A may be communicatively coupled to other computing environments ( Figure 10 not shown), and receive data regarding an interactive / resource network of participating users. In an illustrative operation, a user ( Figure 10 not shown) may interact with computing applications running on devices 1000B to 1000G to obtain desired data and / or execute other computing applications.

[0111] Data and / or computing applications may be stored on one or more servers 1000A and passed to collaborating users via devices 1000B to 1000G on exemplary communication network 920. Participating users ( Figure 10 not shown) may request access to specific data and applications that are wholly or partially loaded on server computer 1000A. This data may be passed between devices 1000B to 1000G and server computer 1000A for processing and storage.

[0112] Server computer 1000A may host computing applications, processes, and applets for generating, authenticating, encrypting, and delivering data and applications, and may communicate with other server computing environments ( Figure 10 not shown), third-party service providers ( Figure 10 not shown), network attached storage (NAS), and storage area networks (SAN) to effect application / data transactions.

[0113] It should be recognized that, for purposes of discussion, Figure 8 the computing architectures shown in Figure 10 and the distributed network computing environments shown in

[0114] have been simplified. It should also be recognized that computing architectures and distributed computing networks may include and utilize many computing components, devices, software programs, network devices, and other components not specifically described herein.

[0115] Clause 1. A computer-implemented method for enabling access to at least a portion of a persistent memory of a host computing device, where at least a portion of the persistent memory is used as volatile memory, the method comprising: receiving, during runtime of the host computing device, a memory allocation request from a virtual machine (VM) application, the memory allocation request including data identifying an amount of persistent memory to be allocated as volatile memory for use by the VM application; creating a file in the persistent memory, the file being usable by the VM application as volatile memory for storing volatile data; sending a file creation confirmation message to the VM application, the file creation confirmation message including data identifying the file in the persistent memory that is usable by the VM application as volatile memory; and storing the volatile data of the VM application in the file in the persistent memory.

[0116] Clause 2. The computer-implemented method according to Clause 1, wherein the data identifying the amount of persistent memory to be allocated includes: parameters for use by the host computing device when creating the file in the persistent memory.

[0117] Clause 3. The computer-implemented method according to Clause 2, wherein at least one of the parameters defines a byte size of the amount of persistent memory to be allocated as volatile memory.

[0118] Clause 4. The computer-implemented method according to at least one of Clauses 2 or 3, wherein at least one of the parameters includes a persistence indicator that indicates that the file will remain in the persistent memory when the runtime of the VM application or the host computing device is terminated.

[0119] Clause 5. The computer-implemented method according to at least one of Clauses 2, 3, or 4, wherein at least one of the parameters includes a non-uniform memory access (NUMA) node identifier that identifies a NUMA node of the host computing device, and wherein the file in the persistent memory is created in the memory of the NUMA node identified by the NUMA node identifier.

[0120] Clause 6. The computer-implemented method according to at least one of Clauses 2, 3, 4, or 5, wherein at least one of the parameters includes a contiguous memory indicator that indicates that the file will be allocated in a contiguous memory region of the persistent memory.

[0121] Clause 7. The computer-implemented method according to at least one of Clauses 2, 3, 4, 5, or 6 further comprises: receiving a memory allocation modification request from a VM application, the memory allocation modification request including data that includes a request to expand the size of a file in persistent memory or a request to shrink the size of a file in persistent memory; and modifying the size of the file in persistent memory based on the data included in the memory allocation modification request from the VM application.

[0122] Clause 8. The computer-implemented method according to at least one of Clauses 2, 3, 4, 5, 6, or 7, wherein at least one of the parameters includes data indicating that the file will become an encrypted file accessible to the VM application.

[0123] Clause 9. A computer-implemented method for requesting allocation of volatile memory as non-volatile memory, the method comprising: generating a memory allocation request that includes an amount of persistent memory to be allocated as volatile memory for use by an application; transmitting the memory allocation request to a host computing device that manages memory allocation to the application; and in response to the memory allocation request, receiving at the application a file creation confirmation message that includes data identifying a file in persistent memory that is available to the application as volatile memory, wherein the memory allocation request and the file creation confirmation message are generated and received, respectively, during runtime of the application.

[0124] Clause 10. The computer-implemented method according to Clause 9, wherein the data identifying the amount of persistent memory to be allocated as volatile memory includes: parameters for use by the host computing device when creating a file in persistent memory.

[0125] Clause 11. The computer-implemented method according to Clause 10, wherein at least one of the parameters defines the byte size of the amount of persistent memory to be allocated as volatile memory.

[0126] Clause 12. The computer-implemented method according to at least one of Clauses 10 or 11, wherein at least one of the parameters includes a persistence indicator that indicates that the file will remain in persistent memory when the application or the host computing device terminates operation.

[0127] Clause 13. The computer-implemented method according to at least one of Clauses 10, 11, or 12, wherein at least one of the parameters includes a non-uniform memory access (NUMA) node identifier that identifies a NUMA node of the host computing device, and wherein the file in persistent memory is created in the memory of the NUMA node indicated by the NUMA node identifier.

[0128] Clause 14. A computer-implemented method according to at least one of Clauses 10, 11, 12, or 13, wherein at least one of the parameters includes a contiguous memory indicator that indicates that a file will be allocated in a contiguous memory region of the persistent memory.

[0129] Clause 15. A computer-implemented method according to at least one of Clauses 10, 11, 12, 13, or 14, wherein at least one of the parameters includes data indicating that a file will become an encrypted file accessible by an application.

[0130] Clause 16. A computing device, comprising: a processor; a persistent memory; and a computer-readable storage medium communicatively coupled to the processor, the computer-readable storage medium having stored thereon computer-executable instructions that, when executed by the processor, cause the processor to: receive a memory allocation request from an application or an operating system (OS), the memory allocation request including data identifying an amount of the persistent memory to be allocated as volatile memory for use by the application or the OS; create a file in the persistent memory to be used as volatile memory by the application or the OS; and send a file creation confirmation message to the application or the OS, the file creation confirmation message including data identifying the file in the persistent memory that is used as volatile memory by the application.

[0131] Clause 17. The computing device according to Clause 16, wherein the data of the memory allocation request includes parameters for use by a host computing device when creating a file in the persistent memory.

[0132] Clause 18. The computing device according to Clause 17, wherein at least one of the parameters defines a byte size of the amount of the persistent memory to be allocated as volatile memory.

[0133] Clause 19. The computing device according to at least one of Clauses 17 and 18, wherein at least one of the parameters includes a persistence indicator that indicates that the file will remain in the persistent memory when an application, the OS, or the host computing device terminates operation.

[0134] Clause 20. The computing device according to at least one of Clauses 17, 18, or 19, wherein the computer-executable instructions, when executed by the processor, further cause the processor to: receive a request from the application or the OS to expand the size of a file in the persistent memory or to shrink the size of a file in the persistent memory.

[0135] The present disclosure presented herein also includes the subject matter described in the following clauses.

[0136] Clause 1. A computer-implemented method for requesting an allocation of byte-addressable persistent memory of a host computing device to be used as volatile memory, the method comprising:

[0137] During runtime of the host computing device, generating a persistent memory allocation request for persistent memory to be used as volatile memory by an application, the persistent memory allocation request including parameters for use by the host computing device when creating a file allocated in the byte-addressable persistent memory to be used as volatile memory by the application;

[0138] Transmitting the persistent memory allocation request specifying the parameters to an operating system of the host computing device, the host computing device managing memory allocation to the application;

[0139] Receiving, at the application, a file creation confirmation message in response to the persistent memory allocation request from the operating system of the host computing device, the file creation confirmation message including data identifying the file in the byte-addressable persistent memory; and

[0140] Storing, by the application, volatile data in the file created in the byte-addressable persistent memory rather than in volatile memory, wherein the file is created according to the parameters.

[0141] Clause 2. The computer-implemented method according to clause 1, wherein the parameters include a persistence indicator indicating that the file will remain in the byte-addressable persistent memory when the application or the host computing device terminates operation.

[0142] Clause 3. The computer-implemented method according to clause 1, wherein the parameters include a non-uniform memory access (NUMA) node identifier identifying a NUMA node of the host computing device, and wherein the file in the byte-addressable persistent memory is created in the memory of the NUMA node indicated by the NUMA node identifier.

[0143] Clause 4. The computer-implemented method according to clause 1, wherein the parameters include a contiguous memory indicator indicating that the file will be allocated in a contiguous memory region of the byte-addressable persistent memory.

[0144] Clause 5. The computer-implemented method according to clause 1, wherein the parameters include data indicating that the file will be an encrypted file accessible to the application.

[0145] Clause 6. The computer-implemented method according to Clause 1, wherein the parameter includes an indication that the amount of memory requested is to be implemented as large pages, superpages, huge pages, or gigantic pages.

[0146] Clause 7. The computer-implemented method according to Clause 1, wherein the persistent memory allocation request further includes the amount of memory requested, and the size of the file is the amount of memory requested.

[0147] Clause 8. A computing device, comprising:

[0148] a processor;

[0149] persistent memory; and

[0150] a computer-readable storage medium in communication with the processor, the computer-readable storage medium having stored thereon computer-executable instructions that, when executed by the processor, cause the processor to:

[0151] During runtime of the host computing device, generate a persistent memory allocation request for persistent memory to be used as volatile memory by an application, the persistent memory allocation request including parameters for use by the host computing device when creating a file in the byte-addressable persistent memory that is allocated to be used as volatile memory by the application;

[0152] Transmit the persistent memory allocation request specifying the parameters to an operating system of the host computing device, the host computing device managing memory allocation to the application;

[0153] Receive, at the application, a file creation confirmation message in response to the persistent memory allocation request from the operating system of the host computing device, the file creation confirmation message including data identifying the file in the byte-addressable persistent memory; and

[0154] Store volatile data by the application in the file created in the byte-addressable persistent memory rather than in volatile memory, wherein the file is created according to the parameters.

[0155] Clause 9. The computing device according to Clause 8, wherein the parameter includes a persistence indicator that indicates that the file will remain in the byte-addressable persistent memory when the application or the host computing device terminates operation.

[0156] Clause 10. The computing device according to Clause 8, wherein the parameter includes a Non-Uniform Memory Access (NUMA) node identifier that identifies a NUMA node of the host computing device, and wherein the file in the byte-addressable persistent memory is created in the memory of the NUMA node indicated by the NUMA node identifier.

[0157] Clause 11. The computing device according to Clause 8, wherein the parameter includes a contiguous memory indicator that indicates that the file will be allocated in a contiguous memory region of the byte-addressable persistent memory.

[0158] Clause 12. The computing device according to Clause 8, wherein the parameter includes data indicating that the file will be an encrypted file accessible to the application.

[0159] Clause 13. The computing device according to Clause 8, wherein the parameter includes an indication that an amount of the requested memory is to be implemented as large pages, superpages, huge pages, or gigantic pages.

[0160] Clause 14. The computing device according to Clause 7, wherein the persistent memory allocation request further includes an amount of the requested memory, and the size of the file is the amount of the requested memory.

[0161] Clause 15. A computer storage medium comprising computer-executable instructions that, when executed by a processor, cause the processor to perform actions including the following:

[0162] During runtime of a host computing device, generate a persistent memory allocation request for persistent memory to be used by an application as volatile memory, the persistent memory allocation request including parameters for use by the host computing device when creating a file in the byte-addressable persistent memory that is allocated to be used by the application as volatile memory;

[0163] Transmit the persistent memory allocation request specifying the parameters to an operating system of the host computing device, the host computing device managing memory allocation to the application;

[0164] Receive, at the application, a file creation confirmation message in response to the persistent memory allocation request from the operating system of the host computing device, the file creation confirmation message including data identifying the file in the byte-addressable persistent memory; and

[0165] The volatile data is stored by the application in the file created in the byte-addressable persistent memory rather than in volatile memory, where the file is created according to the parameters.

[0166] Clause 16. The computer storage medium according to clause 15, wherein the parameter includes a persistence indicator that indicates that the file will remain in the byte-addressable persistent memory when the application or the host computing device terminates operation.

[0167] Clause 17. The computer storage medium according to clause 15, wherein the parameter includes a non-uniform memory access (NUMA) node identifier that identifies the NUMA node of the host computing device, and wherein the file in the byte-addressable persistent memory is created in the memory of the NUMA node indicated by the NUMA node identifier.

[0168] Clause 18. The computer storage medium according to clause 15, wherein the parameter includes a contiguous memory indicator that indicates that the file will be allocated in a contiguous memory region of the byte-addressable persistent memory.

[0169] Clause 19. The computer storage medium according to clause 15, wherein the parameter includes data indicating that the file will become an encrypted file accessible by the application.

[0170] Clause 20. The computer storage medium according to clause 15, wherein the persistent memory allocation request further includes the amount of memory requested, and the size of the file is the amount of memory requested.

[0171] Although the technology has been described in language specific to structural features and / or method acts, it should be understood that the appended claims are not necessarily limited to the described features or acts. Rather, the features and acts are described as example implementations of such technology.

[0172] It should be recognized that the above subject matter may be implemented as a computer-controlled apparatus, a computer process, a computing system, or an article of manufacture, such as a computer-readable storage medium. Among many other benefits, the technology disclosed herein improves efficiency with respect to broad computing resources. Other technical effects beyond those mentioned herein may also be achieved by implementations of the technology disclosed herein.

[0173] The operations of the example methods are illustrated in separate boxes and summarized with reference to these blocks. The methods are illustrated as a logical flow of blocks, each of which can represent one or more operations that can be implemented in hardware, software, or a combination thereof. In the context of software, the operations represent computer-executable instructions stored on one or more computer-readable media that, when executed by one or more processors, enable the one or more processors to perform the recited operations.

[0174] Generally, computer-executable instructions include routines, programs, objects, modules, components, data structures, etc. that perform particular functions or implement particular abstract data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be executed in any order, combined in any order, subdivided into multiple sub-operations, and / or executed in parallel to implement the described process. The described process can be executed by resources associated with one or more (a plurality of) devices, such as one or more internal or external CPUs or GPUs, and / or one or more pieces of hardware logic, such as an FPGA, DSP, or other type of accelerator.

[0175] All of the above methods and processes can be embodied in software code modules executed by one or more general-purpose computers or processors and be fully automated by these software code modules. The code modules can be stored in any type of computer-readable storage medium or other computer storage device. Some or all of the methods can alternatively be embodied in specialized computer hardware.

[0176] Unless otherwise specifically stated, conditional language, such as "can," "could," "might," or "may," among others, is understood in context to mean that certain examples include certain features, elements, and / or steps, while other embodiments do not include certain features, elements, and / or steps. Thus, such conditional language is generally not intended to imply that certain features, elements, and / or steps are required for one or more examples in any way or that one or more examples must include logic for deciding whether certain features, elements, and / or steps are included in any particular example or are to be performed in any particular example, whether or not there is user input or prompting. Unless otherwise specifically stated, conjunctive language, such as the phrase "at least one of X, Y, or Z" is understood to mean that items, terms, etc. can be X, Y, or Z or a combination thereof.

[0177] Any routine description, element, or box in the flowcharts described herein and / or depicted in the accompanying figures should be understood as potentially representing a module, segment, or portion of code that includes one or more executable instructions for implementing specific logical functions or elements in a routine. Alternative implementations are included within the scope of the examples described herein, where elements or functions may be deleted or executed out of the order shown or discussed, including substantially synchronously or in reverse order, depending on the functionality involved, as would be understood by one of ordinary skill in the art. It should be emphasized that the above examples may have many variations and modifications, with the elements being understood as other acceptable examples. All such modifications and variations are intended to be included within the scope of the present disclosure and are protected by the following claims.

Claims

1. A computer-implemented method for enabling access to at least a portion of a byte-addressable persistent memory of a host computing device, wherein at least a portion of the byte-addressable persistent memory is used as volatile memory, the method comprising: Receiving, from an application running on the host computing device, a persistent memory allocation request for a persistent memory that is used as volatile memory by the application, the persistent memory allocation request including parameters for use by the host computing device when creating a file allocated to be used as volatile memory by the application in the byte-addressable persistent memory; Generating a create file instruction including data to cause generation of the file based on the parameters included in the persistent memory allocation request; Creating the file in the byte-addressable persistent memory according to the parameters by mapping a memory address range of physical bits of the byte-addressable persistent memory to be available to the application as the volatile memory; And Sending a file creation confirmation message including data identifying the file in the byte-addressable persistent memory.

2. The computer-implemented method according to claim 1, wherein the parameters include at least one of the following: A persistence indicator indicating that the file will remain in the byte-addressable persistent memory when the application or the runtime of the host computing device is terminated; A non-uniform memory access (NUMA) node identifier that identifies a NUMA node of the host computing device, and wherein the file in the byte-addressable persistent memory is created in the memory of the NUMA node identified by the NUMA node identifier; A contiguous memory indicator indicating that the file will be allocated in a contiguous memory region of the byte-addressable persistent memory; Data indicating that the file will become an encrypted file accessible to the application.

3. The computer-implemented method according to claim 1, further comprising: Storing volatile data of the application in the file created in the byte-addressable persistent memory rather than in volatile memory.

4. A computing device, comprising: A processor; Persistent memory; And A computer-readable storage medium in communication with the processor, the computer-readable storage medium having stored thereon computer-executable instructions that, when executed by the processor, cause the processor to: Receive, from an application running on the computing device, a persistent memory allocation request for a persistent memory that is used as volatile memory by the application, the persistent memory allocation request including parameters for use by the computing device when creating a file allocated to be used as volatile memory by the application in the byte-addressable persistent memory; Generate a create file instruction including data to cause generation of the file based on the parameters included in the persistent memory allocation request; Create the file in the byte-addressable persistent memory according to the parameter by mapping a memory address range of physical bits of the byte-addressable persistent memory that is to be available to the application as the volatile memory; and Send a file creation confirmation message that includes data identifying the file in the byte-addressable persistent memory.

5. The computing device according to claim 4, wherein the parameter includes at least one of the following: A persistence indicator that indicates that the file will remain in the byte-addressable persistent memory when the application or the runtime of the computing device is terminated, A non-uniform memory access (NUMA) node identifier that identifies a NUMA node of the computing device, and wherein the file in the byte-addressable persistent memory is created in the memory of the NUMA node identified by the NUMA node identifier, A contiguous memory indicator that indicates that the file will be allocated in a contiguous memory region of the byte-addressable persistent memory, Data indicating that the file will become an encrypted file accessible to the application, An indication that the requested amount of memory is to be implemented as a large page, a superpage, a huge page, or a gigantic page.

6. The computing device according to claim 4, wherein when executed by the processor, the computer-executable instructions further cause the processor to: Store volatile data of the application in the file created in the byte-addressable persistent memory instead of in the volatile memory.

7. A computer storage medium comprising computer-executable instructions that, when executed by a processor, cause the processor to perform actions comprising: Receive, from an application running on the computing device, a persistent memory allocation request for a persistent memory that is to be used by the application as a volatile memory, the persistent memory allocation request including parameters for use by the computing device when creating a file in the byte-addressable persistent memory that is to be allocated as the volatile memory for the application; Generate a create file instruction that includes data to cause generation of the file based on the parameters included in the persistent memory allocation request; Create the file in the byte-addressable persistent memory according to the parameter by mapping a memory address range of physical bits of the byte-addressable persistent memory that is to be available to the application as the volatile memory; and Send a file creation confirmation message that includes data identifying the file in the byte-addressable persistent memory.

8. The computer storage medium according to claim 7, wherein the parameter includes at least one of the following: A persistence indicator that indicates that the file will remain in the byte-addressable persistent memory when the application or the runtime of the computing device is terminated, A non-uniform memory access (NUMA) node identifier that identifies a NUMA node of the computing device, and wherein the file in the byte-addressable persistent memory is created in the memory of the NUMA node identified by the NUMA node identifier, A contiguous memory indicator that indicates that the file is to be allocated in a contiguous memory region of the byte-addressable persistent memory, Data indicating that the file is to become an encrypted file accessible by the application, An indication that the requested amount of memory is to be implemented as large pages, superpages, huge pages, or gigantic pages.

9. The computer storage medium of claim 7, wherein the computer-executable instructions further cause the processor to perform the actions comprising: storing volatile data of the application in the file created in the byte-addressable persistent memory rather than in volatile memory.

10. A computer-implemented method for requesting allocation of byte-addressable persistent memory of a host computing device to be used as volatile memory, the method comprising: During runtime of a host computing device, generating a persistent memory allocation request for persistent memory to be used as volatile memory by an application, the persistent memory allocation request including parameters for use by the host computing device when creating a file in the byte-addressable persistent memory to be allocated as volatile memory by the application; Transmitting the persistent memory allocation request specifying the parameters to an operating system of the host computing device, the host computing device managing memory allocation to the application; Receiving, at the application, a file creation confirmation message in response to the persistent memory allocation request from the operating system of the host computing device, the file creation confirmation message including data identifying the file in the byte-addressable persistent memory; And Storing, by the application, volatile data in the file created in the byte-addressable persistent memory rather than in volatile memory, wherein the file is created according to the parameters.

Images