Overview
This document describes how to use Virt-awaresched in common scenarios.
VSched consists of a user-mode service vas-daemon and a frontend command-line interface (CLI) tool.
- vas-daemon depends on libvirt to monitor VM events. It binds each vCPU of VMs created before and after vas-daemon startup to a core within the core binding range of the VMs. In this way, vCPU threads are reallocated to CPU cores in the same cluster as much as possible. In addition, it periodically performs inter-cluster CPU resource defragmentation. After being started, vas-daemon collects the CPU topology information in the environment, listens to VM events and CLI commands, and periodically defragments CPU resources.
- The frontend CLI tool vasctl allows you to query vCPU binding information, manually trigger rescheduling, and modify configurations. During execution of an instruction, it parses the instruction and verifies parameters. Upon successful verification, it sets up connections to the server and forwards the instruction. Then, it returns the execution result.
Feature Description
VSched selects proper CPU cores for vCPU threads within the core binding range based on the CPU cluster topology, hyper-threading scheduling, and dynamic core binding, to maximize L3 cache sharing and reduce the cross-cluster distribution of vCPUs. This increases the cache hit ratio during vCPU switchover, prevents performance deterioration caused by vCPU thread drift between CPU cores, and improves virtualization linearity. It provides the following functions:
- CPU core allocation and defragmentation: VSched selects proper CPU cores for vCPUs within the core binding range based on the CPU cluster topology, to minimize cross-cluster VMs. Upon VM destruction, it reclaims CPU cores and performs cluster-level defragmentation.
- Static core binding: VSched binds a vCPU thread to a CPU core so that the thread runs exclusively on this core. If the simultaneous multi-threading (SMT) is enabled, VSched does not differentiate between a physical core and a hyper-thread.
- Dynamic core binding: VSched dynamically binds a vCPU thread to a preferred core. When the core usage is higher than a threshold, the vCPU thread is migrated to another core with better performance. When the core usage falls below the threshold, the vCPU thread reverts to the preferred core. In addition, dynamic core binding takes hyper-threading scheduling into account and allows vCPU threads to run on physical cores as much as possible. The DA_UTIL_TASKGROUP switch controls how the preferred core usage is calculated: When it is enabled, the preferred core usage by the task group is used; when it is disabled, the total preferred core usage is used. Dynamic core binding requires the kernel to support the tidal affinity feature and works with group scheduling.
Benefits
For the new Kunpeng 920 processor models, Virt-awaresched improves performance in both single-VM cross-cluster core binding and multi-VM scenarios.
Key Technologies
Virt-awaresched is based on the Kunpeng microarchitecture and combined with hardware Translation Lookaside Buffer Invalidate (TLBi) broadcast optimization to implement virtualization-aware scheduling and improve virtualization linearity.
Constraints
- Host and guest CPUs are not hot-swappable.
- Special core binding relationships cannot be configured for VM vCPUs. You are advised to bind vCPUs to cores by NUMA node, leave core binding unconfigured (default), or bind vCPUs to cores in the same range (for example, cores 8 to 31).
- cgroup and libvirt may not be aware of VSched's vCPU-core binding configuration, leading to inconsistent configurations.
- Static core binding: Customers need to specify whether to enable the SMT option based on actual services. If the SMT option is enabled, VSched does not differentiate between a physical core and a hyper-thread during vCPU-core binding. In this case, idle physical cores may not be fully utilized in some scenarios.
- Dynamic core binding: If the CPU core usage threshold for triggering migration or the CPU core usage calculation method is inappropriate, the performance may deteriorate in some scenarios. If the vCPU usage of a VM remains 100% and the vCPU does not enter the sleep and wakeup process, and the usage of the core where the vCPU thread is located is greater than 85%, the vCPU thread may not be migrated to another core due to kernel scheduling.
- vCPU overcommitment is not supported for VMs.
- VSched resource usage:
- The average CPU usage during stable running without frequent restarts is less than or equal to 1%.
- During service running, the maximum CPU usage is less than or equal to 100%, and the memory usage is less than or equal to 128 MB.