This section will start with a brief review of Oracle VM's CPU credit scheduler. Next, we will walk through the procedure to pin a virtual machine's CPUs to a subset of an Oracle VM Server's CPU cores using the ovm_vmcontrol utility. The chapter concludes with CPU pinning examples by manually editing a vm.cfg file with the xm command.
Virtual Machine CPU Pinning Road Map
1- Validate the hard partitioned Oracle VM Server CPU topology
2- Pin CPUs with the ovm_vmcontrol Utility
Oracle VM’s default CPU scheduler is the credit scheduler. The credit scheduler uses a credit/debit system to fairly share CPU resources between virtual machines. Credits are assigned to each running virtual machine, along with the allocated fraction of CPU resources. The credit scheduler continually increments/decrements credits from running virtual machines, which is how the credit scheduler balances CPU resources. In many ways, the credit scheduler is like the Linux scheduler. The Linux scheduler is used as the default CPU scheduler with the KVM hypervisor. Both schedulers can preempt processes as needed while trying to ensure proportional fair share allocations.
The default behavior of the credit scheduler is to bind each virtual machine CPU to a separate physical core. For example, when you create a virtual machine with two CPUs, the credit scheduler will map the two virtual machine CPUs to two physical cores. So when pinning virtual machine CPUs, we follow the credit scheduler’s default behavior of mapping virtual machine CPUs to an Oracle VM Server’s CPU cores.
Excluding pinned virtual machine’s, virtual machine CPUs will occasionally bind to different physical cores. A virtual machine's CPUs will bind to different physical cores, due to the credit scheduler’s use of the credit/debit system that dynamically re-balances CPU resources. For example, if you periodically checked an unpinned virtual machine’s CPU mapping, you would see a different CPU mappings throughout the day.
There are two methods to pin virtual machine CPUs. The CPU mapping can be hardcode a virtual machine’s vm.cfg file or mapped using the xm command. The difference between pinning CPUs by hardcoding in the vm.cfg file and with the xm command is the persistence of the CPU mapping. Hard coding the CPU mapping in a virtual machines’s vm.cfg file is persistent between reboots. CPUs that are pinned with the xm command are not persistent between reboots.
Please note that hard partitioning could cause guest performance issues. For example, if you pin a virtual machine’s CPUs to a specific subset of named CPUs without considering how the lower-level I/O interrupts are being assigned, you can end-up hurting performance. I/O interrupts are typically mapped to a specific CPU. If that CPU is not the same as the pinned CPU, the interrupts have to be "re-directed" to the CPU you pinned, which could cause the performance of the guest to decrease. If a hard partitioned virtual machines experience performance issues, the CPU pinning would be an area to investigate.
Tip: All CPU cores are not equal, so you may need to test various virtual CPU mappings using the xm command before pinning CPUs in a vm.cfg file.