[libvirt] [RFC PATCH v2 1/4] numa: describe siblings distances within cells
Wim ten Have
wim.ten.have at oracle.com
Tue Jul 18 14:16:41 UTC 2017
On Wed, 28 Jun 2017 15:21:29 +0100
"Daniel P. Berrange" <berrange at redhat.com> wrote:
> On Wed, Jun 28, 2017 at 03:56:36PM +0200, Wim Ten Have wrote:
> > From: Wim ten Have <wim.ten.have at oracle.com>
> >
> > Add libvirtd NUMA cell domain administration functionality to
> > describe underlying cell id sibling distances in full fashion
> > when configuring HVM guests.
> >
> > [below is an example of a 4 node setup]
Hi Daniel, I think you're best to consult on below issue
too. This given it is related to the changes I am preparing
but was obviously not yet discussed. Your other hint towards
symmetry on distance configuration and autonomous actions
made me more carefully approach whole.
Working <numa> <distance> support, specifically for xenlight
driver I for certain topic related detail consult QEMU/KVM
behavior. Here when describing a guest XML configuration
in libvirt there's this nuance when <numa> comes into the
game. Imagine below.
<vcpu placement='static' current='5'>8</vcpu>
...
<cpu mode='host-passthrough'>
<numa>
<cell id='0' cpus='0,2' memory='262144' unit='KiB'/>
<cell id='1' cpus='1,3' memory='262144' unit='KiB'/>
</numa>
</cpu>
Running QEMU/KVM with such onlines 5 CPUs. This is wrong IMHO.
<wtenhave at kvm26:35> lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 5
On-line CPU(s) list: 0-4
...
NUMA node(s): 2
...
NUMA node0 CPU(s): 0,2,4
NUMA node1 CPU(s): 1,3
My thinking is that <vcpu ... current='_5_' had to be
computed somewhere around under;
virDomainDefParseXML() -> virDomainDefPostParse()
path and forcibly put to '4'.
<vcpu placement='static' current='4'>8</vcpu>
This is of course a <numa> related issue.
Is it worth fixing this (QEMU/KVM) case? If doing that would
that potentially hurt specific use and that way libvirt?
- Wim.
--
Wim ten Have | Consulting Member of Technical Staff
Oracle Linux and VM Development Engineering
ORACLE Nederland BV | Hertogswetering 163-167 | 3543 AS Utrecht/NL
More information about the libvir-list
mailing list