Re: [PATCH 2/3] conf: Initialize the pinning policy for vcpus

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]