On 5/11/22 12:10, Daniel P. Berrangé wrote:
If all we needs is NUMA affinity, not CPU affinity, then it would
be sufficient to create 1 I/O thread per host NUMA node that the
VM needs to use. The job running in the I/O can spawn further
threads and inherit the NUMA affinity. This might be more clever
than it is needed though.
I expect creating/deleting I/O threads is cheap in comparison to
the work done for preallocation. If libvirt is using -preconfig
and object-add to create the memory backend, then we could have
option of creating the I/O threads dynamically in -preconfig mode,
create the memory backend, and then delete the I/O threads again.
I think this is very overengineered. Michal's patch is doing the
obvious thing and if it doesn't work that's because Libvirt is trying to
micromanage QEMU.
As mentioned on IRC, if the reason is to prevent moving around threads
in realtime (SCHED_FIFO, SCHED_RR) classes, that should be fixed at the
kernel level.
Paolo
