Runtime allocation and utilization of persistent storage as volatile storage

Abstract

The described technology enables 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 the persistent memory of a computing device. The file is created in the persistent memory of the computing device during the runtime of a virtual machine (VM) hosted by the computing device. The file can be assigned to the VM. 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). In some implementations, the temporary data is associated with an application executed in the VM.

Description

Background Art

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

[0002] The resources of the host computing device may include one or more processors and memory used to store data of the VM. The memory used to store data of the VM may be volatile memory or non-volatile memory. Volatile memory is generally used to store temporary data required to support the functions of the VM during the runtime of the VM. Data stored in non-volatile memory (which may also be referred to as "persistent memory" herein) 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., upon restart, reboot, or shutdown).

[0003] Generally speaking, firmware, such as a 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, therefore, 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 the amount of non-volatile memory available to the host computing device. However, it is usually necessary to reboot the host computing device to make changes to the configuration of the firmware, which defines the amount of volatile memory and the amount of non-volatile memory available to the host computing device and shareable with the VM.

[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). Because the data access performance of persistent memory is approaching that of volatile memory, the firmware may be configured to allocate some of the persistent memory as volatile memory available to the host computing device and shareable with the VM.

[0006] As described above, the configuration of the host computer can generally only be modified when the host computing device is booted or rebooted. Therefore, during the runtime of a VM hosted by the host computing device, it is not possible to configure persistent memory as volatile memory available to the host computing device. The present disclosure presented herein is made with respect to 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., a host computing device). The technical advantages of the described implementations and technical solutions are numerous. In particular, efficient use of available memory is achieved through the described implementations. For example, the described implementations enable the host computing device to allocate persistent memory for use as volatile memory during the runtime of the host computing device and the VM hosted by the host computing device. Therefore, by using the described implementations and solutions, the current need to reboot the host computing device to access 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 through the implementation of the disclosed technology.

[0008] The technical solution disclosed herein includes creating a file, such as a data structure, in a 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 required to support the functionality of the VM during the runtime of the VM. In some implementations, the temporary data is associated with an application executed in the VM.

[0009] In some implementations, an application executing in a VM generates a memory request, such as a request for volatile memory. The VM can transmit the memory request to a host computing device hosting the VM. For example, a 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 executing on the host computing device.

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

[0011] This summary is provided to introduce a selection of concepts in a simplified form that will be described below in a specific implementation. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. For example, the term "techniques" may refer to system(s), method(s), computer-readable instructions, module(s), algorithm(s), hardware logic, and / or operation(s) as allowed by the context above and the entire document. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The detailed description is described with reference to the accompanying drawings. In the drawings, the leftmost digit(s) of a reference number identifies the digit in which the reference number first appears. The same reference numbers in different drawings indicate similar or identical items.

[0013] Figure 1A , Figure 1B and Figure 2 is a block diagram illustrating a computing device implementing a virtual machine (VM) that can be used with one or more of the described implementations.

[0014] Figure 3 and Figure 4 is a block diagram illustrating a computing device implementing a container that can be used with one or more of the described implementations.

[0015] Figure 5 and Figure 6 is a block diagram illustrating several computing devices configured to create files in persistent storage, which may be used with one or more of the described implementations.

[0016] Figure 7 is a flow chart illustrating aspects of a routine disclosed herein for creating a file in persistent storage for use as volatile storage, according to an exemplary embodiment.

[0017] Figure 8 is a flow chart illustrating aspects of a routine disclosed herein for creating a file in persistent storage for use as volatile storage, according to an exemplary embodiment.

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

[0019] Fig.10 is a network diagram illustrating a distributed computing environment in which aspects of the disclosed technology may be implemented. DETAILED DESCRIPTION

[0020] Conventional computing devices allocate volatile memory and non-volatile memory or persistent memory at boot time, such as when they are powered on or rebooted. A technical solution is provided that enables a computing device to allocate at least a portion of persistent memory as volatile memory during 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 runtime of a virtual machine (VM).

[0021] The technical solution proposed herein includes creating a file in a 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 (e.g., volatile data) that is required to support the functionality of the VM during the runtime of the VM. In some implementations, the temporary data is associated with an application executed in the VM.

[0022] The technical advantages of the described implementations and technical solutions are numerous. Specifically, efficient use of available memory is achieved by the described implementations. For example, the described implementations enable a host computing device to allocate persistent memory for use as volatile memory during runtime of the host computing device and during runtime of a VM hosted by the host computing device. Thus, by using the described implementations and solutions, the conventional requirement to have to reboot the host computing device to access firmware to modify the current allocation of persistent memory and volatile memory is eliminated.

[0023] The present 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 actions to be performed, or information conveyed by these requests, instructions, and other communications. In addition, the requests, instructions, and other communications described herein may be generated by instructions executed by one or more processors of one or more computing devices. For example, instructions may 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 a 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] Typically, host computing device 102 is one or more data processing devices, such as rack-mounted servers or other computing devices. Host computing device 102 may be located in a single physical location or distributed across different physical locations. Host computing device 102 may have different capabilities and computer architectures.

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

[0027] The host computing device 102 may execute a host operating system (OS) 108. The host OS 108 may manage 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 VM monitor (VMM), that 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 a network interface controller (NIC) 118. The hypervisor 110 may virtualize other hardware of the host computing device 102.

[0028] In some implementations, hypervisor 110 manages concurrent execution of one or more VMs, such as VM 104 and VM 106. Each of VMs 104 and 106 provides a virtual instance of physical hardware (e.g., processor 112, persistent memory 114, and volatile memory 116) that can (but need not be) based on host computing device 102 and the hardware architecture of host computing device 102. The virtualized instance of physical hardware associated with host computing device 102 may 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, VM 104 and VM 106 may 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 the 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 pages of the virtual memory 120 to pages of the volatile memory 116. The hypervisor 110 and the memory manager 124 can also map virtual bits or blocks of the virtual memory 120 to 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 with respect to 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 may manage access to virtual memory 120 on behalf of applications 130. In other implementations, applications 130 may access virtual memory 120 directly.

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

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

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

[0038] In some implementations, the host OS 108, the hypervisor 110, and / or the memory manager 124 allocate portions of the persistent memory 114 and portions of the volatile memory 116 to the volatile memory 116. Conventionally, the amount of the persistent memory 114 and the amount of 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 restarting the host computing device 102 using a reboot process or simply a boot process. However, during active runtime instantiations of the VMs 104 and / or VMs 106, rebooting the host computing device 102 may be impossible or impractical.

[0039] The described implementations provide techniques that allow some or all of the persistent memory 114 to be allocated for use as non-volatile memory without the traditional requirement to reboot or boot the host computing device 102. To enable runtime allocation of the 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 the persistent memory 114. In some implementations, a memory address range, whether contiguous or non-contiguous, is defined in the persistent memory 136. The memory address range in the persistent memory 136 can be used as volatile memory.

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

[0041] The application 130 may generate a memory request. The memory request may be provided to the OS 128 for forwarding to the host OS 108. 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. In another example, the memory request may be generated by the OS 128 on behalf of the application 130, or the OS 128 may automatically generate the memory request.

[0042] 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, which may include a request for volatile memory. In some implementations, the memory allocation request may include, by way of data, a request for allocation of persistent memory 114 to be used as volatile memory by one or more of application 130 or 152 and OS 128.

[0043] The memory allocation request may include, but is not limited to, data specifying: (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 persistent memory 114; (5) whether the amount of memory requested is to be implemented as large pages, super pages, huge pages, or gigantic pages; and / or (6) whether the amount of memory requested is to be implemented using persistent memory in a particular NUMA node or 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, the hypervisor 110 may receive a memory request from a VM 104 or an application 152 and forward the memory request to the OS 108 and / or the memory manager 124, as described above.

[0045] The memory manager 124 receives the memory allocation request and evaluates its data and content to determine the parameters contained in the memory allocation request. Based on the 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 the file 136 to be generated according to the parameters described in and encapsulated in the create file instruction based on the parameter details of the memory allocation request. 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 of a computing device 102 and various request flows that can be used with one or more of the described implementations is illustrated. An application 130 can generate a memory request. The memory request can 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 can transmit the memory request directly to the host OS 108. For example, the application 152 can generate the memory request for direct transmission to the host OS 108. In some implementations, the application 152 is a VM application, such as a VM machine 104. In another example, the memory request can be generated by the OS 128 on behalf of the application 130, or the OS 128 can generate the memory request autonomously.

[0048] In response to the memory request from VM 104, host computing device 102, host OS 108, or hypervisor 110 may generate 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 allocation of persistent memory 114 to be used as volatile memory by one or more of application 130 or 152 and OS 128.

[0049] The memory allocation request 138 may include, but is not limited to, data specifying: (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 persistent memory 114; (5) whether the amount of memory requested is to be implemented as large pages, super pages, huge pages, or gigantic pages; and / or (6) whether the amount of memory requested is to be implemented using persistent memory in a particular NUMA node or nodes, where the one or more NUMA nodes are identified by corresponding one or more NUMA node identifiers.

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

[0051] Memory manager 124 receives memory allocation requests and evaluates their data and content to determine parameters contained in memory allocation request 138. Based on policies governing memory usage and evaluation of memory allocation request 138, memory manager 124 generates create file instructions 140 for transmission to persistent storage 114.

[0052] The create file instruction 140 is provided to the persistent memory 114, and the create file instruction 140 includes data to cause the file 136 to be generated according to the parameters stated in and encapsulated in the create file instruction 140 based on the parameter details of the memory allocation request 138. In some implementations, the create file instruction 140 is provided to the persistent memory 114 by the hypervisor 110. 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.

[0053] Now refer to Figure 2 , in the create file instruction 140 (such as Figure 1BAfter forwarding the file to the persistent memory 114, 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 use thereof.

[0055] Additionally, the OS 128, hypervisor 110, and / or memory manager 150 allocates the file 136 to the virtual memory 120 by way of an allocate file instruction 144. Specifically, once the file 136 is allocated to the virtual memory 120, the requesting application 130 or the OS 128 is able to access the file 136, which is allocated to the virtual memory 120 for use as volatile memory to store temporary data, such as data that is typically stored in the virtualized portion of the volatile memory 116.

[0056] Figure 3 A high-level 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 a host computing device 202, can host one or more containers. In the illustrated example, the host computing device 202 is hosting a container 204 and a container 206. The containers 204 and 206 can also be viewed as memory partitions or memory resources associated with the host computing device 202.

[0057] Containers 204 and 206 are similar to Figure 1A , Figure 1B and Figure 2 106. The primary difference between containers 204 and 206 and VMs 104 and 106 is that containers 204 and 206 do not implement an OS. Additionally, containers 204 and 206 do not include virtualized hardware, such as virtual memory 120 and 122. Instead, each of containers 204 and 206 shares the host OS 108 and associated hardware of the host computing device 202. The host OS 108 cooperates with the container manager 208 to arbitrate shared functionality of the host OS 108 and associated hardware of the host computing device 202 between the containers 204 and 206. In some implementations, the container manager 208 may be a hypervisor, such as a 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 in different physical locations. The host computing devices 202 may have different capabilities and computer architectures.

[0059] The host computing devices 202 can communicate with each other via an internal data communication network (not shown). For example, the internal data communication network can 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] Host computing device 202 may also communicate with devices on external networks (such as the Internet) through one or more gateways, which are data processing devices responsible for routing data communication traffic between internal data communication networks and external networks.

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

[0062] In some implementations, container manager 208 can interface with memory manager 124 to allocate memory, such as persistent memory 114 and volatile memory 116, to container 204 and / or container 206. In other implementations, container manager 208 can allocate memory by performing the functions described with reference to 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. Also, 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 following describes the functionality of the host computing device 202 for allocating the persistent memory 114 for use as volatile memory. The functionality for allocating the persistent memory 114 for use as volatile memory will be described with reference to the container 204. Similar functionality may be performed by the container 206 or other applications executing in the host computing device 202.

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

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

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

[0068] The container manager 208 or the host OS 108 may generate a memory allocation request 138. The memory allocation request 138 may be communicated to the 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 large pages, super pages, huge pages, or gigantic pages; and / or (6) whether the amount of memory requested is to be implemented using persistent memory in a particular NUMA node or nodes, where the one or more NUMA nodes are identified by corresponding one or more NUMA node identifiers.

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

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

[0072] Now refer to Figure 4 , after forwarding the create file instruction 140 to the persistent memory 114, the memory manager 124 generates a file creation confirmation 142, which is forwarded to the container manager 208. Alternatively, the host OS 108 or the memory manager 124 may forward the file creation confirmation 142 to the container 204 or the application 130. The file creation confirmation 142 may 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 is able to access the file 136, which is allocated to the requesting application 130 for use as volatile memory to store temporary data (such as data normally used to be stored in the volatile memory 116).

[0073] Figure 5 Actions performed by host computing device 102 are illustrated to modify file 136 that was created in persistent memory 114 by a VM hosted by host computing device 102 , such as VM 104 , for use as volatile memory.

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

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

[0076] The modify file instruction 504 may include a parameter indicating whether the request is: (1) a request to expand or shrink the amount of memory associated with file 136 (e.g., in bytes), (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, super pages, huge pages, or giant pages, (6) a request to implement file 136 in persistent memory associated with a particular NUMA node or nodes, and / or (7) a request to modify persistent attributes associated with file 136.

[0077] Modify file instructions 504 are provided to persistent storage 114. Instructions 504 cause file 136 to be modified according to data defining parameters stated in modify file instructions 504 based on parameter details of file modification request 502 encapsulated therein.

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

[0079] The modify file instruction 604 may be generated by the memory manager 124. The memory manager 124 may generate the modify file instruction 604 in response to a volatile memory request from a container 204, an application 130, an application 152, and / or a hypervisor 208. In some implementations, the memory manager 124 interfaces with a file system of the 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 reduce the amount of memory associated with the file 136 (e.g., in bytes), (2) a request to delete the file 136, (3) a request to encrypt the file 136, (4) a request to move the file 136 to a contiguous portion of the persistent memory 114, (5) a request to implement the file 136 using large pages, super pages, huge pages, or giant pages, (6) a request to implement the file 136 in persistent memory associated with a particular NUMA node or nodes, and / or (7) a request to modify persistent attributes associated with the file 136.

[0081] Modify file instructions 604 are provided to persistent storage 114. Instructions 604 cause file 136 to be modified according to data defining the parameters described in modify file instructions 604.

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

[0083] It should be understood by those of ordinary skill in the art that the operations of the methods disclosed herein are not necessarily presented in any particular order, and that it is possible and contemplated that some or all of the operations are performed in (multiple) alternative orders. For ease of description and illustration, the operations have been presented in the order of demonstration. 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 method shown can be terminated at any time and need not be executed in its entirety. Some or all of the operations of the method and / or substantially equivalent operations can 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 broadly used herein to include routines, applications, application modules, program modules, programs, components, data structures, algorithms, and the like. Computer-readable instructions can 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] Therefore, it should be appreciated that the logical operations described herein are implemented as (1) a sequence of computer-implemented actions or program modules running on a computing system (e.g., device(s) 102 and / or 202), and / or (2) machine logic circuits or circuit modules interconnected in a computing system. Implementation is a matter of choice, depending on the performance and other requirements of the computing system. Therefore, 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 identifying an amount of persistent memory to be allocated as volatile memory for use by a VM (VM application or applications). During runtime of a host computing device, a memory allocation request may be received and associated with the host computing device. For example, memory allocation request 138 may be received by host computing device 102 or host computing device 202. Memory allocation request 138 may be generated by VM 104, VM ​​application 130, application 152, or container 204 in response to a memory request.

[0087] At operation 704 , a file is created in persistent storage for use by the VM application or applications. In some implementations, the file 136 is created in persistent storage 114 that 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 applications. In some implementations, the file 136 created in the persistent memory is allocated to the VM 104, application 152, VM application 130, or OS 128 of the host computing device 102 of the container 204 and / or the application 130 or application 152 of the container 204. Allocating the file to the VM application or applications may include identifying the addressing and length of the file allocated to the VM application or applications.

[0089] At operation 708, a file creation confirmation message is sent to the VM application or applications. The file creation confirmation message may include data identifying a file in the persistent memory for the VM application or applications to use as volatile memory. For example, the file creation confirmation message 142 may be delivered 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 container 204 and / or application 130 of container 204 may use file 136 as volatile memory.

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

[0092] Figure 8 is a flow chart illustrating aspects of a routine 800 disclosed herein for creating a file in persistent storage for use as volatile storage according to an exemplary embodiment. In some implementations, Figure 8 The operations shown in the example routine 800 may be performed by components of one or more computing devices, such as one or more of the devices 102 and / or 202. Thus, instructions associated with the example routine 800 may be executed by one or more processors associated with the devices 102 and / or 202.

[0093] When a memory request is generated at a VM application, VM, or application, routine 800 may begin at operation 802. The memory request may include data identifying a request for volatile memory used by the VM application, VM, or application. In some implementations, the memory request is generated by 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 can manage memory allocations for VM applications, VMs, or applications. In some implementations, the memory request is transmitted to an element of the host computing device 102 or the host computing device 202. For example, in some implementations, the memory request can 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 (also an application) receives the confirmation message. For example, the file creation confirmation message 142 can 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 identifying the file 136 created in the persistent storage 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 a MICROSOFT WINDOWS operating system, a software application, etc.).

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

[0098] Fig. 9 The computer 900 shown in the figure 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, coupling the memory 904 to the CPU 902. A basic input / output system (BIOS or firmware), containing basic routines that help transfer information between elements in the computer 900, such as during startup, can 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 can also be configured to store other types of programs and data.

[0099] The mass storage device 912 is connected to the storage device 912 through the mass storage controller ( Fig. 9 A mass storage controller (not shown) is connected to the CPU 902, and the mass storage controller is connected to the bus 910. The mass storage device 912 and its associated computer readable media provide non-volatile storage for the computer 900. Although the description of computer readable media contained herein refers to a mass storage device, such as a hard disk, a CD-ROM drive, a DVD-ROM drive, or a USB memory key, it should be appreciated by those skilled in the art that the computer readable medium can be any available computer storage medium or communication medium that can be accessed by the computer 900.

[0100] Communication media includes computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and includes any delivery media. The term "modulated data signal" refers to a signal that has one or more of its characteristics changed or set in some way to encode the information in the signal. For example, but not limited to, communication media includes wired media such as a wired network or a direct wired connection and wireless media such as acoustic, video, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.

[0101] For example, but not limited to, 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. For example, 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 disk (DVD), HD-DVD, BLU-RAY or other optical storage devices, cassettes, magnetic tape, magnetic disk storage devices or other magnetic storage devices or any other medium that can be used to store the desired information and can be accessed by the computer 900. For the purpose of the claims, the phrase "computer storage medium" and its variations do not include waves or signals themselves or communication media.

[0102] According to various configurations, the computer 900 can operate in a network environment using logical connections to remote computers through a network, such as network 920. The computer 900 can be connected to the network 920 through a network interface unit 916, which is connected to the bus 910. It should be appreciated that the network interface unit 916 can also be used to connect to any type of network and remote computer system. The computer 900 can also include an input / output controller 918 for receiving and processing input from a number of other devices, including a keyboard, a mouse, a touch input, an electronic pen ( Fig. 9 Likewise, the input / output controller 918 may provide output to a display screen or other type of output device ( Fig. 9 ).

[0103] It should be appreciated that the software components described herein, when loaded into the CPU 902 and executed, can convert the CPU 902 and the entire computer 900 from a general-purpose computing device to a special-purpose computing device that is customized to support the functionality proposed herein. The CPU 902 is constructed of any number of transistors or other discrete circuit elements, which can assume any number of states individually or collectively. 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 convert the CPU 902 by specifying how the CPU 902 transitions between states, thereby converting the transistors or other discrete hardware elements that constitute the CPU 902.

[0104] Encoding the software modules proposed herein can also convert the physical structure of the computer-readable medium proposed herein. In different implementations of this description, the specific conversion 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 primary storage device or an auxiliary storage device, and the like. 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 converting the physical state of the semiconductor memory. For example, the software can convert the state of transistors, capacitors, or other discrete circuit elements that constitute the semiconductor memory. The software can also convert the physical state of such components to store data thereon.

[0105] As another example, the computer readable medium disclosed herein can be implemented using magnetic or optical technology. In such an implementation, the software proposed herein can be converted to its physical state when encoded in a magnetic or optical medium. These conversions can include changing the magnetic properties of a specific location in a given magnetic medium. These conversions can also include changing the physical characteristics or properties of a specific location in a given optical medium to change the optical properties of these locations. Without departing from the scope and spirit of this specification, other conversions of physical media are possible, wherein the previous examples are provided only for the convenience of this discussion.

[0106] In view of the above, 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 Fig. 9The architecture of the computer 900 shown in the figure or a similar architecture may 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 the computer 900 may not include Fig. 9 All components shown in the Fig. 9 Other components not explicitly shown may be utilized in conjunction with Fig. 9 A completely different architecture as shown in .

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

[0108] like Fig.10 As shown in the figure, one or more server computers 1000A can be connected to each other via a communication network 920 (which can be a fixed wired or wireless LAN, WAN, intranet, extranet, peer-to-peer network, virtual private network, Internet, Bluetooth communication network, dedicated low-voltage communication network or other communication network), and the communication network 920 has several devices, such as but not limited to a tablet computer 1000B, a game console 1000C, a smart watch 1000D, a phone 1000E (such as a smart phone), a personal computer 1000F and an AR / VR device 1000G.

[0109] In a network environment where the communication network 920 is the Internet, for example, the server computer 1000A can be a dedicated server computer operable to process data and pass data to and from devices 1000B to 1000G via any of a number of known protocols, such as the Hypertext Transfer Protocol (HTTP), the File Transfer Protocol (FTP), or the Simple Object Access Protocol (SOAP). Additionally, the network computing environment 1000 can utilize various data security protocols, such as Secure Sockets Layer (SSL) or Pretty Good Privacy (PGP). Each of the devices 1000B to 1000G can be equipped with an operating system operable to support one or more computing applications or terminal sessions, such as a web browser ( Fig.10 ) or other graphical user interface ( Fig.10 not shown) or phone desktop environment ( Fig.10 (not shown)), thereby obtaining permission to access server computer 1000A.

[0110] The server computer 1000A may be communicatively coupled to other computing environments ( Fig.10 ), and receives data about the interaction / resource network of participating users. In illustrative operation, a user ( Fig.10 ) can interact with computing applications running on devices 1000B to 1000G to obtain required data and / or execute other computing applications.

[0111] Data and / or computing applications may be stored on one or more servers 1000A and delivered to collaborating users via devices 1000B to 1000G on exemplary communication network 920. Participating users ( Fig.10 1000A) can request access to specific data and applications that are fully or partially loaded on the server computer 1000A. These data can be transferred between the devices 1000B to 1000G and the server computer 1000A for processing and storage.

[0112] The server computer 1000A can host computing applications, processes and applets for generating, authenticating, encrypting and delivering data and applications, and can be used with other server computing environments ( Fig.10 Not shown), third-party service providers ( Fig.10 ), network attached storage (NAS) and storage area network (SAN) to enable application / data transactions.

[0113] It should be recognized that for the sake of discussion, Figure 8 The computational architecture shown in Fig.10 The distributed network computing environment shown in has been simplified. It should also be appreciated that the computing architecture and distributed computing network may include and utilize many computing components, devices, software programs, network devices, and other components not specifically described herein.

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

[0115] Clause 1. A computer-implemented method for enabling access to at least a portion of a persistent memory of a host computing device, at least a portion of the persistent memory being used as volatile memory, the method comprising: receiving a memory allocation request from a virtual machine (VM) application during runtime of the host computing device, 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 a 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 of Clause 1, wherein the data identifying the amount of persistent memory to be allocated comprises: parameters for use by the host computing device when creating the file in the persistent memory.

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

[0118] Clause 4. A computer-implemented method according to at least one of clauses 2 or 3, wherein at least one of the parameters includes a persistence indicator indicating that the file is to be retained in the persistent storage when the runtime of the VM application or the host computing device is terminated.

[0119] Clause 5. A 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 a 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. A computer-implemented method as described in at least one of clauses 2, 3, 4, or 5, wherein at least one of the parameters includes a contiguous memory indicator indicating that the file is to be allocated in a contiguous memory area of ​​the persistent memory.

[0121] Clause 7. A computer-implemented method according to at least one of Clauses 2, 3, 4, 5 or 6, further comprising: receiving a memory allocation modification request from a VM application, the memory allocation modification request comprising data, the data comprising a request for expanding the size of a file in the persistent memory or a request for reducing the size of a file in the persistent memory; and modifying the size of the file in the persistent memory based on the data included in the memory allocation modification request from the VM application.

[0122] Clause 8. A computer-implemented method as recited in 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 is to be an encrypted file accessible by 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, the memory allocation request including identifying 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 receiving a file creation confirmation message at the application in response to the memory allocation request, the file creation confirmation message including data identifying a file in persistent memory that can be used by 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 of Clause 9, wherein the data identifying the amount of persistent memory to be allocated as volatile memory comprises parameters for use by the host computing device when creating a file in the persistent memory.

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

[0126] Clause 12. A computer-implemented method as recited in at least one of Clauses 10 or 11, wherein at least one of the parameters includes a persistence indicator indicating that the file is to be retained in the persistent storage when the application or the host computing device terminates runtime operation.

[0127] Clause 13. A 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 a host computing device, and wherein the file in the 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 indicating that the file is to be allocated in a contiguous memory area of ​​the persistent memory.

[0129] Clause 15. The computer-implemented method of at least one of clauses 10, 11, 12, 13, or 14, wherein at least one of the parameters includes data indicating that the file is to be an encrypted file accessible by the application.

[0130] Clause 16. A computing device comprising: a processor; a persistent memory; and a computer-readable storage medium in communication with the processor, the computer-readable storage medium having computer-executable instructions stored thereon, which, 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 persistent memory to be allocated as volatile memory for use by the application or OS; create a file in the persistent memory for use as volatile memory by the application or OS; and send a file creation confirmation message to the application or OS, the file creation confirmation message including data identifying a file in the persistent memory for use as volatile memory by the application.

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

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

[0133] Clause 19. A computing device according to at least one of clauses 17 and 18, wherein at least one of the parameters includes a persistence indicator, the persistence indicator indicating that the file is to be retained in the persistent storage when the application, OS, or host computing device terminates runtime operation.

[0134] Clause 20. A 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 an application or the OS to expand the size of a file in the persistent memory or to reduce the size of a file in the persistent memory.

[0135] Although the technology has been described in language specific to structural features and / or methodological 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 the technology.

[0136] It should be appreciated that the above subject matter can be implemented as a computer-controlled device, 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 relative to a wide range of computing resources. Other technical effects other than those mentioned herein can also be achieved by implementing the technology disclosed herein.

[0137] The operations of the example methods are illustrated with individual blocks and summarized with reference to these blocks. The methods are illustrated as a logical flow of blocks, each of which may represent one or more operations that may 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 operations described.

[0138] In general, computer executable instructions include routines, programs, objects, modules, components, data structures, etc., which perform specific functions or implement specific 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 may be performed in any order, combined in any order, subdivided into multiple sub-operations and / or performed in parallel to implement the described processes. The described processes may be performed by resources associated with one or more (multiple) devices (such as one or more internal or external CPUs or GPUs) and / or one or more pieces of hardware logic (such as FPGAs, DSPs or other types of accelerators).

[0139] 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 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 be alternatively embodied in specialized computer hardware.

[0140] Unless otherwise specifically stated, conditional language, such as "may," "could," "might," or "might," among others, is understood in context to indicate that certain examples include certain features, elements, and / or steps while other embodiments do not. Thus, such conditional language is generally not intended to imply that certain features, elements, and / or steps are in any way required of one or more examples or that one or more examples must include logic for determining 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, linking language, such as the phrase "at least one of X, Y, or Z," is understood to indicate that an item, term, etc. can be X, Y, or Z, or a combination thereof.

[0141] Any routine description, element or frame in the flow chart described in this article and / or depicted in the accompanying drawings should be understood as potentially representing the part of a module, segment or code, which includes one or more executable instructions for implementing a specific logic function or element in the routine. Alternative implementations are included in the scope of the examples described in this article, wherein elements or functions can be deleted or not executed in the order shown or discussed, including basically synchronously or in reverse order, depending on the functionality involved, as understood by those skilled in the art. It should be emphasized that the above examples may have many variations and modifications, and elements therein are understood to be other acceptable examples. All these modifications and variations are intended to be included in 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, the at least a portion of the byte-addressable persistent memory being used as volatile memory, the method comprising: receiving, by an operating system of the host computing device during runtime of the host computing device, from an application running on the host computing device, a persistent memory allocation request for persistent memory used as volatile memory by the application, the persistent memory allocation request comprising an amount of the requested memory in bytes and parameters for use by the host computing device when creating a file in the byte-addressable persistent memory allocated for use as volatile memory by the application; generating a create file instruction including data to cause generation of the file based on the requested amount of memory in bytes and the parameters contained 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 used by the application as the volatile memory; as well as sending a file creation confirmation message, the file creation confirmation message including data identifying the file in the byte-addressable persistent memory; as well as The volatile data of the application is stored in the file created in the byte-addressable persistent memory instead of in volatile memory.

2. The computer-implemented method of claim 1 , wherein the parameters include a persistence indicator indicating that the file is to be retained in the byte-addressable persistent memory when the application or a runtime of the host computing device is terminated.

3. The computer-implemented method of claim 1 , wherein the parameters include a non-uniform memory access NUMA node identifier, the 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 a memory of the NUMA node identified by the NUMA node identifier. 4 . The computer-implemented method of claim 1 , wherein the parameters include a contiguous memory indicator indicating that the file is to be allocated in a contiguous memory region of the byte-addressable persistent memory.

5. The computer-implemented method of claim 1, wherein the parameters include an indication that the requested amount of memory is to be implemented as large pages, super pages, huge pages, or gigantic pages.

6. The computer-implemented method of claim 1 , wherein the parameters include: a persistence indicator indicating that the file is to be retained in the byte-addressable persistent storage when the application or a runtime of the host computing device is terminated; a non-uniform memory access NUMA node identifier, the 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 a memory of the NUMA node identified by the NUMA node identifier; a contiguous memory indicator indicating that the file is to be allocated in a contiguous memory area of ​​the byte-addressable persistent memory; as well as Data indicating that the file is to be an encrypted file accessible to the application.

7. The computer-implemented method of claim 1, wherein the application is a virtual machine application and the create file instructions are provided via a hypervisor.

8. The computer-implemented method of claim 1 , wherein creating the file in the byte-addressable persistent memory comprises: Physical bits or blocks of the byte-addressable persistent memory are mapped to one or more memory partitions or memory resources.

9. The computer-implemented method of claim 1, wherein the method is performed at least in part by a background thread of an operating system.

10. The computer-implemented method of claim 1 , further comprising: The file is assigned to the application by identifying the addressing and length of the file to the application.

11. A computer-implemented method for requesting allocation of byte-addressable persistent memory of a host computing device for use as volatile memory, the method comprising: generating, during runtime of the host computing device, by an application running on the host computing device, a persistent memory allocation request for persistent memory used by the application as volatile memory, the persistent memory allocation request comprising an amount of the requested memory in bytes and parameters for use by the host computing device when creating a file in the byte-addressable persistent memory allocated for use by the application as volatile memory; transmitting the persistent memory allocation request specifying the requested amount of memory and the parameters to an operating system of the host computing device, the host computing device managing memory allocation for the application; receiving, at the application, from the operating system of the host computing device, in response to the persistent memory allocation request, a file creation confirmation message including data identifying the file in the byte-addressable persistent memory; as well as Volatile data is stored by the application in the file created in the byte-addressable persistent memory instead of in volatile memory, wherein the file has a size of the requested amount of memory and is created according to the parameters.

12. The computer-implemented method of claim 11, wherein the parameters include a persistence indicator indicating that the file is to be retained in the byte-addressable persistent memory when the application or host computing device terminates runtime operations.

13. The computer-implemented method of claim 11, wherein the parameters include 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 a memory of the NUMA node indicated by the NUMA node identifier.

14. The computer-implemented method of claim 11, wherein the parameters include a contiguous memory indicator indicating that the file is to be allocated in a contiguous memory region of the byte-addressable persistent memory.

15. The computer-implemented method of claim 11, wherein the parameter includes data indicating that the file is to be an encrypted file accessible by the application.

16. A computing device comprising: processor; Persistent storage; as well as a computer-readable storage medium in communication with the processor, the computer-readable storage medium having computer-executable instructions stored thereon, the computer-executable instructions, when executed by the processor, causing the processor to: A persistent memory allocation request is received by an operating system (OS) of the computing device from an application running on the computing device for persistent memory used by the application as volatile memory, the persistent memory allocation request comprising an amount of requested memory in bytes and parameters for use by the computing device when creating a file in byte-addressable persistent memory of the computing device, wherein the parameters are at least one of: a persistence indicator indicating that the file is to be retained in the byte-addressable persistent storage when the application, OS, or computing device terminates runtime operation; a non-uniform memory access NUMA node identifier, the NUMA node identifier identifying a NUMA node of the computing device, and wherein the file in the byte-addressable persistent memory is created in a memory of the NUMA node identified by the NUMA node identifier; a contiguous memory indicator indicating that the file is to be allocated in a contiguous memory area of ​​the byte-addressable persistent memory; or data indicating that the file is to be an encrypted file accessible to the application, 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 for use as volatile memory by the application; as well as A file creation confirmation message is sent, the file creation confirmation message including data identifying the file in the byte-addressable persistent memory.

17. The computing device of claim 16, 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 the file in the byte-addressable persistent memory.

18. The computing device of claim 16, 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 reduce the size of the file in the persistent memory.

19. The computing device of claim 18, wherein the parameters include: an indication that the amount of memory requested is to be implemented as large pages, super pages, huge pages, or gigantic pages; as well as A non-uniform memory access NUMA node identifier identifies a NUMA node of the computing device, and wherein the file in the persistent memory is created in a memory of the NUMA node identified by the NUMA node identifier.

20. The computing device of claim 16, wherein the data identifying the file in the byte-addressable persistent memory identifies an addressing and a length of the file.

Images