xapi-project / xen-api / 19731708290
80%
master: 80%

LAST BUILD BRANCH: private/edvint/memorytest6
DEFAULT BRANCH: master
Ran
Jobs 1
Files 34
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 80.459%. First build
19731708290

push

github

edwintorok 
CA-420968: avoid large performance hit on small NUMA nodes

NUMA optimized placement can have a large performance hit on machines with
small NUMA nodes and VMs with a large number of vCPUs.
For example a machine that has 2 sockets, which can run at most 32 vCPUs in a
single socket (NUMA node), and a VM with 32 vCPUs.

Usually Xen would try to spread the load across actual cores, and avoid the
hyperthread siblings, e.g. using CPUs 0,2,4,etc.
But when NUMA placement is used all the vCPUs must be in the same NUMA node.
If that NUMA node doesn't have enough cores, then Xen will have no choice but
to use CPUs 0,1,2,3,etc.

Hyperthread siblings share resources, and if you try to use both at the same
time you get a big performance hit, depending on the workload.

Avoid this by "requesting" cores=vcpus for each VM,
which will make the placement algorithm choose the next size up in terms of
NUMA nodes (i.e. instead of 1 NUMA node, use 2,3 as needed, falling back to using
all nodes if needed).

The potential gain from reducing memory latency with a NUMA optimized placement
(~20% on Intel Memory Latency Checker: Idle latency) is outweighed by
the potential loss due to reduced CPU capacity (40%-75% on OpenSSL, POV-Ray, and
OpenVINO), so this is the correct trade-off.

If the NUMA node is large enough, or if the VMs have a small number of vCPUs
then we still try to use a single NUMA node as we did previously.

The performance difference can be reproduced and verified easily by running
`openssl speed -multi 32 rsa4096` on a 32 vCPU VM on a host that has 2 NUMA
nodes, with 32 PCPUs each, and 2 threads per core.
This introduces a policy that can control whether we want to filter out
NUMA nodes with too few cores.

Although we want to enable this filter by default, we still want
an "escape hatch" to turn it off if we find problems with it.
That is why the "compat" setting (numa_placement=true) in xenopsd.conf
reverts back to the old policy, which is now named explicit... (continued)

3504 of 4355 relevant lines covered (80.46%)

0.8 hits per line

Jobs
ID Job ID Ran Files Coverage
1 python3.11 - 19731708290.1 34
80.46
 GitHub Action Run
Source Files on build 19731708290