On a Thursday in 2023, Michal Privoznik wrote:
Currently, the ThreadContext object is generated whenever we see .host-nodes attribute for a memory-backend-* object. The idea was that when the backend is pinned to a specific set of host NUMA nodes, then the allocation could be happening on CPUs from those nodes too. But this may not be always possible. Users might configure their guests in such way that vCPUs and corresponding guest NUMA nodes are on different host NUMA nodes than emulator thread. In this case, ThreadContext won't work, because ThreadContext objects live in context of the emulator thread (vCPU threads are moved around by us later, when emulator thread finished its setup and spawned vCPU threads - see qemuProcessSetupVcpus()). Therefore, memory allocation is done by emulator thread which is pinned to a subset of host NUMA nodes, but tries to create a ThreadContext object with a disjoint subset of host NUMA nodes, which fails. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2154750 Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> --- src/qemu/qemu_command.c | 11 ++++++----- .../hugepages-memaccess2.x86_64-latest.args | 9 +++------ .../memory-hotplug-virtio-mem.x86_64-latest.args | 3 +-- .../numatune-memnode.x86_64-latest.args | 9 +++------ .../numatune-system-memory.x86_64-latest.args | 3 +-- 5 files changed, 14 insertions(+), 21 deletions(-)
Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx> Jano
Attachment:
signature.asc
Description: PGP signature
