Memory management

Edit online

The memory configured for a virtual server appears as physical memory to the guest operating system but is realized as a Linux® virtual address space.

Virtual server memory has the same characteristics as virtual memory used by other Linux processes. For example, it is protected from access by other virtual servers or applications running on the host. It also allows for memory overcommitment, that is, the amount of virtual memory for one or more virtual servers may exceed the amount of physical memory available on the host.

Memory is organized in fixed size blocks called pages. Each virtual server memory page must be backed by a physical page of the host. Since more virtual pages than physical pages can exist, it is necessary that the content of currently unused virtual pages can be temporarily stored on a storage volume (swap device) and retrieved upon access by the guest. The activity of storing pages to and retrieving them from the disk is called swapping.

Figure 1. Swapping

Since disk storage access is significantly slower than memory access, swapping will slow down the execution of a virtual server even though it happens transparently for the guest. Careful planning of virtual server memory handling is therefore essential for an optimal system performance.

Tip:
  • Plan a memory ratio of not more than virtual-to-real to 2:1
  • Configure the minimum amount of memory necessary for each virtual server

Even if the defined virtual server memory exceeds the physical host memory significantly, the actual memory usage of a host may be considerably less than the defined amount. There are multiple techniques allowing the host to efficiently deal with memory overcommitment:

Using huge pages

You can back the virtual memory of a virtual server with 1 MB huge pages of host memory. Depending on your workload, huge pages can result in performance gains.

Prerequisites on the host
  • The host must be configured with enough 1 MB pages to satisfy the needs of its guests.
  • The kvm module must be loaded with the hpage parameter to support guest-configurations with huge-page memory backing.
For more information, see the large pages (huge pages in recent editions) section in Device Drivers, Features, and Commands.
Restrictions for guests
  • Transparent huge pages (THP) are not supported.
  • The huge page size must be 1 MB.
  • Memory overcommitment is not possible.
  • Huge pages cannot be freed.
  • Collaborative memory management is disabled on guests that use huge pages.
  • KVM guests that use huge pages cannot be KVM hosts for higher-level guests.
  • You cannot use huge pages for KVM guests that are to run in IBM® Secure Execution mode.

For details about configuring huge pages for a guest, see Configuring huge pages.

Collaborative memory management

A guest operating system can mark memory pages as unused or volatile with the IBM Z® Collaborative Memory Management Assist (CMMA) facility. This allows the host to avoid unnecessary disk swapping because unused pages can simply be discarded. Current Linux operating systems make use of CMMA. The subset of the CMMA facility as used by Linux is enabled in KVM, therefore transparently ensuring efficient physical host memory usage, while still allowing the virtual server to use all of the defined virtual memory if needed.

Ballooning

KVM implements a virtual memory balloon device that serves the purpose of controlling the physical host memory usage of a virtual server. With the balloon device, the host can request that the guest gives up memory. This could be done to re-balance the resource allocations between virtual servers to adapt to changing resource needs.

Whether and to which extent the guest honors the request depends on a few factors not controlled by the host, such as, whether or not a balloon device driver is installed in the guest, or whether there's enough memory that can be freed.

Unlike for CMMA, the memory given up by the balloon device is removed from the virtual server and cannot be reclaimed by the guest. As this can cause adverse effects and even lead to program or operating system failures due to low memory conditions, it should only be used in well-understood situations. By default, you should disable the balloon device by configuring <memballoon model="none"/>.

Memory tuning

Another way to control virtual server memory usage is by means of the Linux cgroups memory controller. By specifying a soft limit the amount of physical host memory used by a virtual server can be restricted once the host is under high memory pressure, that is, the host is experiencing high swapping activity. Again, this would typically be done to re-balance resource allocations between virtual servers.

Since the virtual server memory available to the guest is not modified, applying a soft limit is transparent, except for the performance penalty caused by swapping. If swapping becomes excessive, time-critical processes may be affected, causing program failures. Therefore the soft limit should be applied carefully as well.

Figure 2. Applying the soft limit

The virtual server memory soft limit can be controlled statically using the soft_limit child element of the memtune element or dynamically using the virsh memtune command.