Patent ID: 12190171

DETAILED DESCRIPTION

Described herein are systems and methods for memory encryption for memory ballooning related memory allocation techniques for execution environments.

Memory ballooning is a dynamic memory management technique for execution environments (e.g., virtual machines, containers, applications, etc.) to allow the host system to reclaim unused memory from certain execution environments and allocate the reclaimed memory to other execution environments. In one example, an execution environment may release memory that is no longer being used to the hypervisor. The released memory may be placed in a reserved memory pool called a balloon. The hypervisor may then re-allocate the released memory in the balloon to other execution environments or for use by the hypervisor, host operating system, underlying hardware device, or a combination thereof. The released memory may then be removed from the balloon and returned to the execution environment at a later time.

In some systems, the hypervisor may request a size of guest memory (e.g., such as 2 MB, 8 MB, etc., or an amount of memory pages) to be made available to the hypervisor. “Memory page” herein shall refer to a contiguous portion of memory of a certain size. For example, a standard memory page may have the size of 4 KB, while a huge page may have the size of 2 MB or 1 GB. The execution environment may have memory pages that are free or can be freed and, thus, may search for such unused guest memory of the requested size. In some examples, the execution environment may allocate multiple portions of unused guest memory from different locations to satisfy the memory request. However, allocating portions from different locations may degrade performance of the execution environment due to memory fragmentation caused by breaking up contiguous partitions of guest memory, such as huge pages. In another example, the execution environment may break up a contiguous portion of unused guest memory until obtaining the requested size of guest memory. For example, responsive to a memory request of 2 MB, the execution environment may identify an 8 MB contiguous portion of unused guest memory, break up the portion into two 4 MB partitions, break up one of the 4 MB partitions into two 2 MB partitions, and release one of the two 2 MB partitions to the hypervisor. However, allocating large portions of contiguous memory depletes the amount of contiguous free memory available on the execution environment, which also may degrade performance of the execution environment due to memory fragmentation. Fragmentation of the guest memory may lead to performance degradation because the execution environment may not be able to satisfy large, contiguous memory allocation requests from applications. As such, it is desirable to prevent guest memory fragmentation from placing guest memory portions in a reserved memory pool and releasing host memory to the hypervisor (e.g., inflating a memory balloon).

Aspects of the present disclosure address the above and other deficiencies by implementing memory ballooning related memory allocation techniques for execution environments. In particular, aspects of the present disclosure provide technology that allows a hypervisor to specify a size range of requested guest memory, and inflate a memory balloon with any sized set of guest memory within the requested range. This allows the hypervisor to minimize fragmentation when inflating the memory balloon increasing the likelihood that the hypervisor may identify a portion of guest memory the exact size of the memory request, rather than allocating multiple portions of unused guest memory or breaking up a contiguous portion of guest memory. In an example, the hypervisor may maintain a list of free (e.g., unused) memory pages for each execution environment (e.g., for one or more containers). The list may be included in a data structure, such as, for example, a table. Each entry in the list may reference a set of memory pages that are contiguous in a guest address space. For example, each entry may be one or more contiguous standard memory pages, one or more contiguous huge pages, or any combination thereof. The operating system of the hypervisor may receive a request, from a management application, for guest memory to be made available to the hypervisor. The request may include a range of the desired size of guest memory. For example, the request may include a minimum size of guest memory requested and a maximum size of guest memory. The operating system may then identify a set of contiguous guest memory in the list of free memory pages that is that is greater than or equal to the minimum size of memory requested, and less than or equal to the maximum size of memory requested. The operating system may then release the set of contiguous guest memory to the hypervisor. The released memory may be placed in a reserved memory pool (e.g., a balloon).

In an illustrative example, an execution environment may include entries of 2 MB, 2 MB, 5 MB, and 8 MB of free memory pages. The hypervisor may request a minimum of 4 MB of guest memory, and a maximum of 6 MB of guest memory. In response, the operating system of the hypervisor may query the list of free memory pages, and identify the 5 MB entry. The operating system may then release memory pages associated with the 5 MB entry to the hypervisor. In conventional systems, the hypervisor may have allocated both 2 MB portions, or broken up the 8 MB portion into two 4 MB portions to allocate a 4 MB portion. Both scenarios would have increased memory fragmentation.

Various aspects of the above referenced methods and systems are described in details herein below by way of examples, rather than by way of limitation. The examples provided below discuss a virtualized computer system where memory movement may be initiated by aspects of a hypervisor, a host operating system, a virtual machine, or a combination thereof. In other examples, the memory movement may be performed in a non-virtualized computer system that is absent a hypervisor or other virtualization features discussed below.

FIG.1depicts an illustrative architecture of elements of a computer system100, in accordance with an implementation of the present disclosure. It should be noted that other architectures for computer system100are possible, and that the implementation of a computing device utilizing implementations of the disclosure are not necessarily limited to the specific architecture depicted. Computer system100may be a single host machine or multiple host machines arranged in a cluster and may include a rackmount server, a workstation, a desktop computer, a notebook computer, a tablet computer, a mobile phone, a palm-sized computing device, a personal digital assistant (PDA), etc. In one example, computing device100may be a computing device implemented with x86 hardware. In another example, computing device100may be a computing device implemented with PowerPC®, SPARC®, or other hardware. In the example shown inFIG.1, computing device100may include execution environments110A-C, hypervisor120, hardware devices130, and a network140.

Hypervisor120, also be known as a virtual machine monitor (VMM), may manage the execution of one or more execution environments and provide the execution environments with access to one or more underlying computing devices (e.g., hardware or virtualized resources). Hypervisor120may interact with hardware devices130and provide hardware virtualization, operating-system virtualization, other virtualization, or a combination thereof. Hardware virtualization may involve the creation of one or more virtual machines that emulate an instance of a physical computing machine. Operating-system-level virtualization may involve the creation of one or more virtual machines that emulate an instance of an operating system. In one example, hypervisor120may be part of a non-virtualized operating system that is absent hardware virtualization and operating-system-level virtualization and each of the execution environments110A-C may be an application process managed by the non-virtualized operating system. In another example, each of execution environments110A-C may be or execute within a separate virtual machine or container. In either example, the hypervisor may be implemented as part of a kernel and execute as one or more processes in kernel space (e.g., privileged mode, kernel mode, root mode).

In the example shown, hypervisor120may run directly on the hardware of computer system100(e.g., bare metal hypervisor). In other examples, hypervisor120may run on or within a host operating system (not shown). Hypervisor120may manage system resources, including access to hardware devices130, and may manage execution of execution environments110A-C on a host machine. This includes provisioning resources of a physical central processing unit (“CPU”) to each execution environment110A-C running on the host machine. Provisioning the physical CPU resources may include associating one or more vCPUs with each execution environment110A-C. VCPUs may be provisioned by a core of the physical host CPU or a number of time slots reserved from one or more cores of the physical host CPU. VCPUs may be implemented by an execution thread that is scheduled to run on a physical host CPU. Software executing in execution environment110A-C may operate with reduced privileges such that hypervisor120retains control over resources. Hypervisor120retains selective control of the processor resources, physical memory, interrupt management, and input/output (“I/O”).

Execution environments110A-C may include a sequence of instructions that can be executed by one or more processing devices (e.g., physical processing devices134). A execution environment may be managed by hypervisor120or may be a part of hypervisor120. For example, hypervisor120may execute as one or more execution environments that cooperate to manage resources accessed by execution environments110A-C. Each execution environment may include one or more processing threads, processes, other stream of executable instructions, or a combination thereof. A processing thread (“thread”) may be the smallest sequence of programmed instructions managed by hypervisor120. A process may include one or more threads and may be an instance of an executable computer program.

In some implementations, execution environment110A-C may be an executable container (hereafter “container”) or run a container. Containers may include application images built from pre-existing application components and source code of users managing the application. An image may refer to data representing executables and files of the application used to deploy functionality for a runtime instance of the application. In one implementation, the image can be built using a Docker™ tool and is referred to as a Docker image. In other implementations, the application images can be built using other types of containerization technologies. An image build system (not pictured) can generate an application image for an application by combining a preexisting ready-to-run application image corresponding to core functional components of the application (e.g., a web framework, database, etc.) with source code specific to the application provided by the user. The resulting application image may be pushed to an image repository (not shown) for subsequent use in launching instances of the application images for execution.

In various implementations, a container may be a secure process space on the execution environment110A-C to execute functionality of an application. A process space is the volume of memory which is allocated for potential memory addresses related to a computing device. In some implementations, a container is established at execution environment110A-C with access to certain resources of the underlying node, including memory and storage. In one implementation, containers may be established using the Linux Containers (LXC) method. In further implementations, containers may also be established using cgroups, SELinux™, and kernel namespaces, to name a few examples.

In some implementations, execution environment110A-C may execute guest executable code that uses an underlying emulation of physical resources, such as, for example, guest memory114A-C. Guest memory114A-C may be any virtual memory, logical memory, physical memory, other portion of memory, or a combination thereof for storing, organizing, or accessing data. Guest memory114A-C may represent the portion of memory that is designated by hypervisors120for use by one or more respective execution environments110A-C. Guest memory114A-C may be managed by host operating system125and may be segmented into guest pages. The guest pages may each include a contiguous or non-contiguous sequence of bytes or bits and may have a page size that is the same or different from a memory page size used by hypervisor120. Each of the guest page sizes may be a fixed-size, such as a particular integer value (e.g., 4 KB, 2 MB) or may be a variable-size that varies within a range of integer values.

In the example shown inFIG.1, hypervisor120may include memory manager122, guest operating system125, and hypervisor memory123. Hypervisor memory123(e.g., host memory) may be the same or similar to the guest memory and may be managed by hypervisor120. Hypervisor memory123may be segmented into host pages, which may be in different states. The states may correspond to unallocated memory, memory allocated to guests, and memory allocated to hypervisor(s). The unallocated memory may be host memory pages and guest memory pages that have not yet been allocated by hypervisor memory123or were previously allocated by hypervisor120and have since been deallocated (e.g., freed) by hypervisor120. The memory allocated to guests may be a portion of hypervisor memory123that has been allocated by hypervisor120to execution environment110A-C and corresponds to guest memory of execution environment114A-C. Other portions of hypervisor memory may be allocated for use by hypervisor120, host operating system125, hardware device, other module, or a combination thereof. Hypervisor memory may include memory balloon124, discussed below.

Host operating system125may include executable code that manages applications, device drivers, execution environments110A-C, other executable code, or a combination thereof. Host operating system125may include operating systems such as, for example, Microsoft® Windows®, Linux®, Solaris®, etc. may execute operations that manage guest memory114A-C, memory balloon124, balloon driver126, and allocation component128respectively. Balloon driver126and allocation component128are used by way of example, and may be any type of device driver, application, program, etc.

Memory manager122may be a management application that enables memory balloon operations by allowing hypervisor120to obtain and use memory pages from execution environment110A-C using, for example, memory balloon124, balloon driver126and/or allocation component128. Memory ballooning generally refers to a method of virtual memory management that allows hypervisor120to use memory allocated to any one of execution environment110A-C. Memory manager122may further track and manage mappings between guest memory114A-C and hypervisor memory123. For example, memory manager122may maintain a table, list or other structure that associates an address of guest memory114A-C (e.g., a guest address) with an address of corresponding hypervisor memory123(e.g., a host address).

Balloon driver126may be a computer program installed on host operating system125used to perform memory balloon operations involving guest memory114A-C. In an example, hypervisor120uses balloon driver126to perform memory balloon operations involving guest memory114A-C. For example, hypervisor120may use balloon driver126to inflate and deflate memory balloon124to reclaim or return guest memory114A-C from/to execution environment110-C. Balloon driver126may be loaded into host operating system125as a pseudo-device driver, and may have no external interface to host operating system125. Accordingly, balloon driver126may not be known to host operating system125, and hypervisor120may communicate with balloon driver126over a private communication channel. In some implementations, a single balloon driver126may be used for two or more execution environments110A-C. In other implementations, each execution environment110A-C may be assigned a respective balloon driver126.

Memory balloon124may be a reserved memory pool inaccessible to execution environment110A-C. For example, memory pages that have been placed in memory balloon124may be hidden from execution environment110A-C, inaccessible to execution environment110A-C, or protected from execution environment110A-C access. In one example, memory balloon124may refer to a classification or status of memory. For example, memory pages removed from guest memory114A-C may be tagged with a status (e.g., “reserved,” “unavailable,” etc.) to indicate that corresponding memory pages may not be used by execution environment110A-C. In some implementations, a singe memory balloon124may be used for two or more execution environments110A-C. In other implementations, each execution environment110A-C may be assigned a respective memory balloon124.

In an example, execution environment110A-C may have guest memory114A-C that is free or can be freed. Memory ballooning allows hypervisor120to use memory allocated to execution environment110A-C. Hypervisor120may borrow memory allocated to execution environment110A-C by inflating memory balloon124. For example, memory manager122may send a memory request to balloon driver126over the private communication channel. The memory request may specify a target memory balloon124size or size range corresponding to an amount of memory sought by hypervisor120. The balloon driver126may inflate memory balloon124in response to receiving a request for guest memory114A-C from memory manager122. In some implementations, balloon driver126may inflate a memory balloon124by pinning memory pages from guest memory114A-C in the memory balloon124. In some implementations, balloon driver126inflates a memory balloon124by placing a number of memory pages from guest memory114A-C in a reserved area of host operating system125associated with memory balloon124. For example, the reserved area may be inaccessible to the execution environment110A-C and/or may prevent execution environment110A-C from performing operations involving memory pages pinned in memory balloon124.

Allocation component128may enable hypervisor120to specify a size range of requested guest memory and may enable execution environment110A-C to inflate memory balloon124with a set of guest memory within the requested range. In particular, allocation component128may maintain a list of unused guest memory114A-C. For example, allocation component128may maintain a list where each entry references a set of free memory pages contiguous in the guest address space. Each entry may be one or more contiguous standard memory pages, one or more contiguous huge pages, or any combination thereof. The list may be included in a data structure, such as, for example, a table.

Further, allocation component128may receive memory requests from hypervisor120via, for example memory manager122. Each memory request may include a size range of desired guest memory. In particular, the request may include a minimum size of guest memory requested and a maximum size of guest memory. For example, the memory request may specify a size of guest memory requested (e.g., 2 KB, 5 MB, 1 GB, etc.), an amount of one or more types of memory pages requested (e.g., 12 standard memory pages, 4 huge memory pages, etc.) or any combination thereof. Responsive to the memory request, memory allocation component128may identify an entry from the list of a set of unused guest memory that is greater than or equal to the minimum size of memory requested, and less than or equal to the maximum size of memory requested. The allocation component128may then instruct the balloon driver126to inflate the balloon driver125with the guest memory from the identified entry. Allocation component128is discussed in more detail below in regards toFIG.2.

In some implementations, memory manager122may be associated with a particular level of privilege that may be the same or similar to protection levels (e.g., processor protection rings). The privilege level may indicate an access level to computing devices (e.g., memory, processor, or other virtual or physical resources). In one example, the privilege levels may correspond generally to a user mode (e.g., reduced privilege mode, non-root mode, non-privileged mode) and a hypervisor mode (e.g., enhanced privilege mode, kernel mode, root mode). In some implementations, memory manager may execute in a user mode to access resources assigned to the execution environments and may be restricted from accessing resources associated with kernel space or with another user space process (e.g., other portion of user space). In some implementations, balloon driver and allocation component may execute in the hypervisor mode to access resources associated with the kernel space and the user space. In other examples, there may be a plurality of privilege levels, and the privilege levels may include a first level (e.g., ring 0) associated with a hypervisor/kernel, a second and third level (e.g., ring 1-2), and a fourth level (e.g., ring 3) that may be associated with user space applications. In some implementations, memory manager122may communicate with memory balloon124, balloon driver126and/or allocation component128using a context switch (e.g., system call or hypercall).

Hardware devices130may provide hardware resources and functionality for performing computing tasks. Hardware devices130may include one or more physical storage devices132, one or more physical processing devices134, other computing devices, or a combination thereof. One or more of hardware devices130may be split up into multiple separate devices or consolidated into one or more hardware devices. Some of the hardware device shown may be absent from hardware devices130and may instead be partially or completely emulated by executable code.

Physical storage devices132may include any data storage device that is capable of storing digital data and may include volatile or non-volatile data storage. Volatile data storage (e.g., non-persistent storage) may store data for any duration of time but may lose the data after a power cycle or loss of power. Non-volatile data storage (e.g., persistent storage) may store data for any duration of time and may retain the data beyond a power cycle or loss of power. In one example, physical storage devices132may be physical memory and may include volatile memory devices (e.g., random access memory (RAM)), non-volatile memory devices (e.g., flash memory, NVRAM), and/or other types of memory devices. In another example, physical storage devices132may include one or more mass storage devices, such as hard drives, solid state drives (SSD)), other data storage devices, or a combination thereof. In a further example, physical storage devices132may include a combination of one or more memory devices, one or more mass storage devices, other data storage devices, or a combination thereof, which may or may not be arranged in a cache hierarchy with multiple levels.

Physical processing devices134may include one or more processors that are capable of executing the computing tasks. Physical processing devices134may be a single core processor that is capable of executing one instruction at a time (e.g., single pipeline of instructions) or may be a multi-core processor that simultaneously executes multiple instructions. The instructions may encode arithmetic, logical, or I/O operations. In one example, physical processing devices134may be implemented as a single integrated circuit, two or more integrated circuits, or may be a component of a multi-chip module (e.g., in which individual microprocessor dies are included in a single integrated circuit package and hence share a single socket). A physical processing device may also be referred to as a central processing unit (“CPU”).

Network140may be a public network (e.g., the internet), a private network (e.g., a local area network (LAN), a wide area network (WAN)), or a combination thereof. In one example, network140may include a wired or a wireless infrastructure, which may be provided by one or more wireless communications systems, such as a wireless fidelity (WiFi) hotspot connected with the network140and/or a wireless carrier system that can be implemented using various data processing equipment, communication towers, etc.

FIG.2is a block diagram illustrating example components and modules of computer system200, in accordance with one or more aspects of the present disclosure. Computer system200may comprise executable code that implements one or more of the components and modules and may be implemented within a hypervisor, a host operating system, a guest operating system, hardware firmware, or a combination thereof. In the example shown, computer system200may include allocation component128, balloon driver126, memory manager122, and guest memory230. Allocation component128may include free memory manager212, search module214, and instruction module216. Guest memory230may be similar to guest memory114A-C, and may include unreserved partition232and reserved partition234. Unreserved partition232may include any portion of guest memory (e.g., guest memory pages) that is available for use by a execution environment (e.g., execution environment110A-C). Reserved partition234may include any portion of guest memory that is used to inflate a memory balloon (e.g., memory balloon124). For example, the memory pages in reserved partition234may be pinned in the memory balloon or placed in a reserved area of the host operating system associated with the memory balloon (thus inaccessible to the execution environment). In some implementations, memory manager122may operate in user space, while balloon driver126and allocation component128may operate in kernel space.

Free memory manager212may maintain a list free (e.g., unused) memory pages in free memory table225. The list of free memory pages may relate to one or more execution environments110A-C (e.g., guest memory of a container). Free memory table225may be any type of data structure used to store records of memory pages that are contiguous in a guest address space. Each entry in the free memory table225may reference a set of one or more contiguous standard memory pages, one or more contiguous huge pages, or any combination thereof. In some implementations, free memory manager212may implement a buddy memory allocation technique and free memory pages may be maintained in a buddy allocated data structure. The buddy memory allocation technique is an algorithm that manages memory in power of two increments. In particular, guest memory may be broken up into blocks of pages where each block is a power of two number of pages. The exponent for the power of two sized block may be referred to as an order. For example, order0may be indicative of free page blocks of size 20(e.g., one memory page), order1may be indicative of free page blocks of size 21(e.g., two memory pages), order10may be indicative of free page blocks of size 210(e.g., 1024 memory pages), etc. If a block of a desired size is not available, a larger block may be broken up in half, where one half may be used for allocation consideration and the other half is placed into free memory table225for a lower order. If the half used for consideration is too large, then the half may be further broken up into two more halves, and so on until the desired size is available. This allows allocation component128to divide the guest memory into partitions to satisfy a memory request.

Memory manager122may send a memory request to allocation component128for guest memory to be made available to the hypervisor. In an example, memory manager122may send the memory request in response to detecting a low amount of available hypervisor memory123by examining resources or performance counters. In another example, memory manager122may receive a notification from performance monitoring software indicating that a low hypervisor memory123condition exists. The memory request may specify a size range of guest memory requested. For example, the memory request may include a minimum size of guest memory requested and a maximum size of guest memory requested. In some implementations, the minimum size may be a standard memory page and the maximum size may be a huge page. In some implementations, the minimum size may be a huge page and the maximum size may be multiple huge pages. Those skilled in the art would understand that any size may be used for the minimum size of guest memory requested and the maximum size of guest memory requested.

Search module214may search free memory table225for a set of guest memory that is within the size range specified in the memory request. In an example, search component may begin the looking up the smallest available order and determining whether the block size of that order will satisfy the memory request. Responsive to the block size not satisfying the memory request, search module214may move towards the next smallest available order. Once an entry is located that can satisfy the memory request (e.g., a block size between the minimum size of guest memory requested and the maximum size of guest memory requested), instruction module216may instruct the balloon driver126to mark the memory pages that are correlated to that entry as reserved (e.g., inflate the memory balloon), and release the memory pages to the memory manager112. Free memory manager212may then update the free memory table225by removing the entry.

In an illustrative example, free memory table225may include entries of 4 KB, 1 MB, 2 MB, and 4 MB of free memory pages. The hypervisor may request a minimum of ½ MB of guest memory, and a maximum of 2 MB of guest memory. In response, search module214may query the free memory table225starting from the smallest available order, and identify the 4 KB entry. Free memory manager212may determine that the 4 KB entry will not satisfy the memory request, then move towards the next smallest available order, and identify the 1 MB entry. Since the 1 MB entry is greater than the minimum requested size of ½ MB, and less than the maximum requested size of 2 MB, instruction module216may then instruct balloon driver220to release the block of memory pages of the 2 MB entry to the hypervisor.

In some implementations, free memory table225may not include an entry to satisfy a memory request. Accordingly, the search module214may identify an entry with a set of contiguous memory pages larger than the size range of the memory request. The instruction module216may then break up the identified set until a portion of the set can satisfy the memory request, upon which that portion may be released to the hypervisor. The remainder of the set may be placed into free memory table225for a lower order. As such, a set of contiguous memory pages is not broken up unless it exceeds the maximum requested size.

In an illustrative example, free memory table225may include entries of 4 KB, 4 MB, and 8 MB of contiguous free memory pages. The hypervisor may request a minimum of ½ MB of guest memory, and a maximum of 2 MB of guest memory. In response, search module214may query the free memory table225starting from the smallest available order, and identify the 4 KB entry. Free memory manager212may determine that the 4 KB entry will not satisfy the memory request, then move towards the next smallest available order, and identify the 4 MB entry. Since the 4 MB block is greater than the maximum requested size of 2 MB, instruction module216may instruct memory manager212to break up the block into two blocks of 2 MB each, and update the free memory table225. Search module214may then select one of 2 MB blocks, determine that the block is greater than the minimum requested size of ½ MB, and equal to the maximum requested size of 2 MB, and instruction module216may instruct balloon driver126to release this block of memory pages to the hypervisor.

In some implementations, search module214may not identify any suitable entries in free memory table225. Accordingly, instruction module216may instruct the execution environment to page-out (e.g., write memory pages to disk) a portion of guest memory to free some guest memory. Free memory manger212may then update free memory table225and search module214may initiate the search process again by querying free memory table225starting from the smallest available order. In some implementations, free memory manager212may periodically analyze guest memory230to update the free memory table225.

FIG.3depicts a flow diagram of an illustrative example of a method300for inflating a memory balloon with a set of guest memory within a requested range, in accordance with one or more aspects of the present disclosure. Method300and each of its individual functions, routines, subroutines, or operations may be performed by one or more processors of the computer device executing the method. In certain implementations, method300may be performed by a single processing thread. Alternatively, method300may be performed by two or more processing threads, each thread executing one or more individual functions, routines, subroutines, or operations of the method. In an illustrative example, the processing threads implementing method300may be synchronized (e.g., using semaphores, critical sections, and/or other thread synchronization mechanisms). Alternatively, the processes implementing method300may be executed asynchronously with respect to each other.

For simplicity of explanation, the methods of this disclosure are depicted and described as a series of acts. However, acts in accordance with this disclosure can occur in various orders and/or concurrently, and with other acts not presented and described herein. Furthermore, not all illustrated acts may be required to implement the methods in accordance with the disclosed subject matter. In addition, those skilled in the art will understand and appreciate that the methods could alternatively be represented as a series of interrelated states via a state diagram or events. Additionally, it should be appreciated that the methods disclosed in this specification are capable of being stored on an article of manufacture to facilitate transporting and transferring such methods to computing devices. The term “article of manufacture,” as used herein, is intended to encompass a computer program accessible from any computer-readable device or storage media. In one implementation, method300may be performed by a kernel of a hypervisor as shown inFIG.1or by an executable code of a host machine (e.g., host operating system or firmware), an execution environment (e.g., guest operating system or virtual firmware), other executable code, or a combination thereof.

Method300may be performed by processing devices of a server device or a client device and may begin at block302. At block302, the operating systems of a hypervisor running an execution environment maintains a list of free memory pages related to the execution environment. Each entry in the list may reference a set of memory pages that are contiguous in a guest address space. The list may be maintained in a buddy allocated data structure. In some implementations, the execution environment may be a container, a virtual machine, an application, etc.

At block304, the operating system of the hypervisor receives, from an application executing on the hypervisor, a memory request for guest memory to be made available to the hypervisor. The memory request may include a minimum size of guest memory requested and a maximum size of guest memory. For example, the minimum size of memory requested may be a standard memory page and the maximum size of memory requested may be a huge page. In some implementations, the request may be sent using a system call or a hypercall.

At block306, responsive to identifying a set of contiguous guest memory pages in the list of free memory pages that is greater than or equal to the minimum size of memory requested, and less than or equal to the maximum size of memory requested, the operating system releases the set of contiguous guest memory pages to the hypervisor. For example, the operating system may identify the smallest set of contiguous guest memory pages that is greater than or equal to the minimum size of the memory requested and less than or equal to the maximum size of memory requested. The released set of contiguous guest memory pages may be placed in a reserved memory pool (e.g., a memory balloon).

In some implementations, responsive to failing to identify, in the list of free memory pages, a set of contiguous guest memory pages that is greater than or equal to the minimum size of memory requested and less than or equal to the maximum size of memory requested, the operating system may satisfy the memory request by allocating a part of a portion of guest memory greater than the maximum size of memory requested (e.g., break apart a portion of guest memory). In some implementations, responsive to failing to identify, in the list of free memory pages, a set of contiguous guest memory pages that is greater than or equal to the minimum size of memory requested and less than or equal to the maximum size of memory requested, the operating system may page-out a portion of guest memory. Responsive to completing the operations described herein above with references to block306, the method may terminate.

FIG.4depicts a block diagram of a computer system400operating in accordance with one or more aspects of the present disclosure. Computer system400may be the same or similar to computer system200and computing device100and may include one or more processing devices and one or more memory devices. In the example shown, computer system400may include free memory manager410, search module420, and an instruction module430.

Free memory manager410may maintain a list of free memory pages related to an execution environment. Each entry in the list may reference a set of memory pages that are contiguous in a guest address space. The list may be maintained in a buddy allocated data structure.

Search module420may receive, from an management application of a hypervisor, a memory request for guest memory to be made available to the hypervisor. The memory request may include a minimum size of guest memory requested and a maximum size of guest memory. For example, the minimum size of memory requested may be a standard memory page and the maximum size of memory requested may be a huge page. Search module420may search the list of free memory pages for a set of memory pages to satisfy the memory request.

Responsive to search module420identifying a set of contiguous guest memory pages in the list of free memory pages that is greater than or equal to the minimum size of memory requested, and less than or equal to the maximum size of memory requested, instruction module430may release the set of contiguous guest memory pages to the hypervisor. For example, search module420may identify the smallest set of contiguous guest memory pages that is greater than or equal to the minimum size of the memory requested and less than or equal to the maximum size of memory requested. The released set of contiguous guest memory pages may be placed in a reserved memory pool (e.g., a memory balloon).

In some implementations, responsive to failing to identify, in the list of free memory pages, a set of contiguous guest memory pages that is greater than or equal to the minimum size of memory requested and less than or equal to the maximum size of memory requested, the free memory manager410may satisfy the memory request by allocating a part of a portion of guest memory greater than the maximum size of memory requested (e.g., break apart a portion of guest memory). In some implementations, responsive to failing to identify, in the list of free memory pages, a set of contiguous guest memory pages that is greater than or equal to the minimum size of memory requested and less than or equal to the maximum size of memory requested, the instruction module may page-out a portion of guest memory.

FIG.5depicts a flow diagram of one illustrative example of a method500for inflating a memory balloon with a set of guest memory within a requested range, in accordance with one or more aspects of the present disclosure. Method500may be similar to method500and may be performed in the same or a similar manner as described above in regards to method300. Method500may be performed by processing devices of a server device or a client device and may begin at block502.

At block502, a processing device maintains a list of free memory pages. Each entry in the list may reference a set of memory pages that are contiguous in a guest address space. The list may be maintained in a buddy allocated data structure. In some implementations, the processing device may run a container, a virtual machine, an application, etc.

At block504, the processing device receives, from a management application of a hypervisor, a memory request for guest memory to be made available to the hypervisor. The memory request may include a minimum size of guest memory requested and a maximum size of guest memory. For example, the minimum size of memory requested may be a standard memory page and the maximum size of memory requested may be a huge page.

At block506, responsive to identifying a set of contiguous guest memory pages in the list of free memory pages that is greater than or equal to the minimum size of memory requested, and less than or equal to the maximum size of memory requested, the processing device releases the set of contiguous guest memory pages to the hypervisor. For example, the processing device may identify the smallest set of contiguous guest memory pages that is greater than or equal to the minimum size of the memory requested and less than or equal to the maximum size of memory requested. The released set of contiguous guest memory pages may be placed in a reserved memory pool (e.g., a memory balloon).

In some implementations, responsive to failing to identify, in the list of free memory pages, a set of contiguous guest memory pages that is greater than or equal to the minimum size of memory requested and less than or equal to the maximum size of memory requested, the processing device may satisfy the memory request by allocating a part of a portion of guest memory greater than the maximum size of memory requested (e.g., break apart a portion of guest memory). In some implementations, responsive to failing to identify, in the list of free memory pages, a set of contiguous guest memory pages that is greater than or equal to the minimum size of memory requested and less than or equal to the maximum size of memory requested, the processing device may page-out a portion of guest memory. Responsive to completing the operations described herein above with references to block506, the method may terminate.

FIG.6depicts a block diagram of a computer system operating in accordance with one or more aspects of the present disclosure. In various illustrative examples, computer system600may correspond to computing device100ofFIG.1or computer system200ofFIG.2. The computer system may be included within a data center that supports virtualization. Virtualization within a data center results in a physical system being virtualized using execution environments to consolidate the data center infrastructure and increase operational efficiencies. A execution environment may be a program-based emulation of computer hardware. For example, the execution environment may operate based on computer architecture and functions of computer hardware resources associated with hard disks or other such memory. The execution environment may emulate a physical computing environment, but requests for a hard disk or memory may be managed by a virtualization layer of a computing device to translate these requests to the underlying physical computing hardware resources. This type of virtualization results in multiple execution environments sharing physical resources.

In certain implementations, computer system600may be connected (e.g., via a network, such as a Local Area Network (LAN), an intranet, an extranet, or the Internet) to other computer systems. Computer system600may operate in the capacity of a server or a client computer in a client-server environment, or as a peer computer in a peer-to-peer or distributed network environment. Computer system600may be provided by a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a server, a network router, switch or bridge, or any device capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that device. Further, the term “computer” shall include any collection of computers that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methods described herein.

In a further aspect, the computer system600may include a processing device602, a volatile memory604(e.g., random access memory (RAM)), a non-volatile memory606(e.g., read-only memory (ROM) or electrically-erasable programmable ROM (EEPROM)), and a data storage device616, which may communicate with each other via a bus608.

Processing device602may be provided by one or more processors such as a general purpose processor (such as, for example, a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a microprocessor implementing other types of instruction sets, or a microprocessor implementing a combination of types of instruction sets) or a specialized processor (such as, for example, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), or a network processor).

Computer system600may further include a network interface device622. Computer system600also may include a video display unit610(e.g., an LCD), an alphanumeric input device612(e.g., a keyboard), a cursor control device614(e.g., a mouse), and a signal generation device620.

Data storage device616may include a non-transitory computer-readable storage medium624on which may store instructions626encoding any one or more of the methods or functions described herein, including instructions for implementing methods300or500and for allocation component122, and modules illustrated inFIGS.1and2.

Instructions626may also reside, completely or partially, within volatile memory604and/or within processing device602during execution thereof by computer system600, hence, volatile memory604and processing device602may also constitute machine-readable storage media.

While computer-readable storage medium624is shown in the illustrative examples as a single medium, the term “computer-readable storage medium” shall include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of executable instructions. The term “computer-readable storage medium” shall also include any tangible medium that is capable of storing or encoding a set of instructions for execution by a computer that cause the computer to perform any one or more of the methods described herein. The term “computer-readable storage medium” shall include, but not be limited to, solid-state memories, optical media, and magnetic media.

The methods, components, and features described herein may be implemented by discrete hardware components or may be integrated in the functionality of other hardware components such as ASICS, FPGAs, DSPs or similar devices. In addition, the methods, components, and features may be implemented by firmware modules or functional circuitry within hardware devices. Further, the methods, components, and features may be implemented in any combination of hardware devices and computer program components, or in computer programs.

Unless specifically stated otherwise, terms such as “initiating,” “transmitting,” “receiving,” “analyzing,” or the like, refer to actions and processes performed or implemented by computer systems that manipulates and transforms data represented as physical (electronic) quantities within the computer system registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices. Also, the terms “first,” “second,” “third,” “fourth,” etc. as used herein are meant as labels to distinguish among different elements and may not have an ordinal meaning according to their numerical designation.

Examples described herein also relate to an apparatus for performing the methods described herein. This apparatus may be specially constructed for performing the methods described herein, or it may comprise a general-purpose computer system selectively programmed by a computer program stored in the computer system. Such a computer program may be stored in a computer-readable tangible storage medium.

The methods and illustrative examples described herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used in accordance with the teachings described herein, or it may prove convenient to construct more specialized apparatus to perform methods300or500and one or more of its individual functions, routines, subroutines, or operations. Examples of the structure for a variety of these systems are set forth in the description above.

The above description is intended to be illustrative, and not restrictive. Although the present disclosure has been described with references to specific illustrative examples and implementations, it will be recognized that the present disclosure is not limited to the examples and implementations described. The scope of the disclosure should be determined with reference to the following claims, along with the full scope of equivalents to which the claims are entitled.