On 2012年10月10日 23:34, Martin Kletzander wrote:
On 10/10/2012 01:14 PM, Osier Yang wrote:
There are two branches to specifiy the pinning policy for vcpus.

1) def->cpuset:

    <vcpu cpuset='0-10,^6'>6</vcpu>

2) def->cputune.vcpupins:

    <cputune>
      <vcpupin vcpuid='1' cpuset='0-5'/>
    </cputune>

def->cputune.vcpupins only maintains the pinning policy only for
vcpus have<vcpupin>  specified explictly, this works fine before

s/explictly/explicitely/, but...

cgroup is widely used for domain. But since now cgroup uses
def->cputune.vcpupins to setup the cgroups for each vcpus thread,
it means the vcpus which doesn't has<vcpupin>  specified will
be ignored for cgroup setting.


... anyway, I didn't quite get that for the first time. However IIUC for
the second time I think it's enough to mention that in case there are
both cpuset and cputune with vcpupin, we don't enforce the cpuset for
vcpus not specified in the cputune.

OK, maybe mine version is not that readable either :-)

To fix the problem, the patch initialize vcpupin for each vcpu
which doesn't has<vcpupin>  specified as def->cpuset.

Problem example without this patch:

1. % virsh start dom
Domain dom started


2. % virsh dumpxml dom
<vcpu placement='static' cpuset='3'>4</vcpu>

3. % virsh vcpuinfo dom
VCPU: 0
CPU: 0
State: running
CPU time: 8.3s
CPU Affinity: yyyyyyyy

VCPU: 1
CPU: 4
State: running
CPU time: 2.4s
CPU Affinity: yyyyyyyy

VCPU: 2
CPU: 0
State: running
CPU time: 4.1s
CPU Affinity: yyyyyyyy

VCPU: 3
CPU: 1
State: running
CPU time: 2.8s
CPU Affinity: yyyyyyyy



/me knocking the head.....

Never mind to ignore this set now, I made a pricinple mistake,
the "cpuset" for "<vcpupin>" should not inherit "cpuset" of "<vcpu>".
They are for different purposes. "cpuset" of "<vcpu>" is to set
the pinning policy for domain process, while "cpuset" of "<vcpupin>"
is to set the pinning policy for vcpu thread.

BTW, the new <emlatorpin> is conflicts with "cpuset" of "<vcpu>",
we just have too much XML tags for NUMA tuning. /sigh. But let's
settle down it later.

Regards,
Osier

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to