Re: [PATCH] util: NUMA aware memory preallocation

[Daniel P . Berrangé]

On Wed, May 11, 2022 at 01:07:47PM +0200, Paolo Bonzini wrote:
> 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.

Calling it micromanaging is putting a very negative connotation on
this. What we're trying todo is enforce a host resource policy for
QEMU, in a way that a compromised QEMU can't escape, which is a
valuable protection. 

> 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.

We use cgroups where it is available to us, but we don't always have
the freedom that we'd like. Sometimes the deployment scenario of
libvirt means that we're stuck with whatever cgroup libvirtd is
launched in and sched_setaffinity is our only way to confine QEMU,
so wanting to prevent use of sched_setaffinity is reasonable IMHO.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|