| Latest revision |
Your text |
| Line 6: |
Line 6: |
| | <span style="color: red;">'''Note: When hugepages are configured this portion of memory is taken away from the Host. This means the Host will no longer be able to use it. Keep this in mind.'''</span> | | <span style="color: red;">'''Note: When hugepages are configured this portion of memory is taken away from the Host. This means the Host will no longer be able to use it. Keep this in mind.'''</span> |
| | | | |
| − | === Debian (Ubuntu/Mint/Lubuntu/PopOS/etc) === | + | === Debain (Ubuntu/Mint/Lubuntu/PopOS/etc) === |
| | First check if Linux isn't already using Hugepages with: <code>cat /proc/meminfo | grep Huge</code>. | | First check if Linux isn't already using Hugepages with: <code>cat /proc/meminfo | grep Huge</code>. |
| | If the output resembles the following: | | If the output resembles the following: |
| Line 55: |
Line 55: |
| | </syntaxhighlight> | | </syntaxhighlight> |
| | Now restart the computer. | | Now restart the computer. |
| − |
| |
| − | === Assigning Hugepages to VM ===
| |
| | | | |
| | To make the VM use Hugepages enter the VM's .XML file and add <code><memoryBacking><hugepages/></memoryBacking></code> to the memory section: | | To make the VM use Hugepages enter the VM's .XML file and add <code><memoryBacking><hugepages/></memoryBacking></code> to the memory section: |
| Line 80: |
Line 78: |
| | to the hyperv section of the VM's .XML file. | | to the hyperv section of the VM's .XML file. |
| | <syntaxhighlight lang=text> | | <syntaxhighlight lang=text> |
| − | ...
| + | <related state='on'/> |
| − | <hyperv>
| + | <vapic state='on'/> |
| − | <related state='on'/>
| + | <spinlocks state='on' retries='8191'/> |
| − | <vapic state='on'/>
| + | <vpindex state='on'/> |
| − | <spinlocks state='on' retries='8191'/>
| + | <runtime state='on'/> |
| − | <vpindex state='on'/>
| + | <synic state='on'/> |
| − | <runtime state='on'/>
| + | <stimer state='on'/> |
| − | <synic state='on'/>
| + | </syntaxhighlight> |
| − | <stimer state='on'/>
| |
| − | ...
| |
| − | </syntaxhighlight>
| |
| − | This edit doesn't help the VM perform better as much as it helps preserve system resources if the plan is to run multiple simultaneous instances.
| |
| | | | |
| | == vcpupin == | | == vcpupin == |
| − | vcpupin is the process where-in each vCPU assigned to the VM is tied to a physical core/thread. Configuring this has the most profound impact when dealing with a system that has multiple NUMA Nodes because it forces requests to memory to stay on one node without having to cross Intel's QPI links or AMD's Infinity Fabric. This also helps by tying the vCPUs to the Node that is directly connected to the GPU.
| |
| − |
| |
| − | <span style="color: red;">'''NOTE: In many cases a function in the BIOS known as Memory Interleave will obfuscate the NUMA Nodes making the system treat multiple sockets or multiple dies as one UMA(Uniform Memory Access) Node. This is a problem for multiple reasons. To fix this find Memory Interleave in your BIOS and set it from Auto -> Channel. If Memory Interleave does not have these options on a single socket system then chances are the system only operates in UMA mode. In such case this is fine.'''</span>
| |
| − |
| |
| − | === Identifying CPU Affinity ===
| |
| − | Their are a couple of options available to determine what PCI_e device and CPU threads are connected to which NUMA Node. On Debian <code>lscpu</code> & <code>lspci -vnn</code> can both be used to determine which node a PCI_e device is connected to and which threads belong to that node.
| |
| − |
| |
| − | Another option is lstopo (the <code>hwloc</code> package). This application provides a GUI overview of the cores/threads and what PCI_e device(s) are connected to which.
| |
| − |
| |
| − | === Assigning CPU Affinity ===
| |
| − | To tie cores/threads to a VM open the VM's .XML file and find the <code>vcpu placement</code> section. Beneath this you will append <code>cputune</code> and modify it's configuration:
| |
| − | <syntaxhighlight lang=text>
| |
| − | <vcpu placement='static'>16</vcpu>
| |
| − | <cputune>
| |
| − | <vcpupin vcpu='0' cpuset='0'/>
| |
| − | <vcpupin vcpu='1' cpuset='1'/>
| |
| − | <vcpupin vcpu='2' cpuset='2'/>
| |
| − | <vcpupin vcpu='3' cpuset='3'/>
| |
| − | <vcpupin vcpu='4' cpuset='8'/>
| |
| − | <vcpupin vcpu='5' cpuset='9'/>
| |
| − | <vcpupin vcpu='6' cpuset='10'/>
| |
| − | <vcpupin vcpu='7' cpuset='11'/>
| |
| − | </cputune>
| |
| − | </syntaxhighlight>
| |
| − | CPU tune works on a per thread basis. If NUMA Node 0 or NUMA Node 1 were threads 0-3,8-11 then you would assign these to the VM's vCPU's with the above example.
| |
| − |
| |
| − | === Verifying CPU Affinity ===
| |
| − | To verify if the CPU threads have been successfully pinned to the VM the <code>virsh vcpupin name-of-vm</code> command can be used. The output for a VM with 8 vCPUs configured as above would look like this:
| |
| − | <syntaxhighlight lang=text>
| |
| − | VCPU CPU Affinity
| |
| − | ----------------------
| |
| − | 0 0
| |
| − | 1 1
| |
| − | 2 2
| |
| − | 3 3
| |
| − | 4 8
| |
| − | 5 9
| |
| − | 6 10
| |
| − | 7 11
| |
| − | </syntaxhighlight>
| |
| − | In the event that your system only uses UMA(Uniform Memory Access) the impact of pinning threads is definitely less pronounced but some benefit can still be gained.
| |
