5:38 p.m.
----- Original Message -----
From: "Dor Laor" <dlaor(a)redhat.com>
To: gkotton(a)redhat.com
Cc: engine-devel(a)ovirt.org, "Eduardo Habkost" <ehabkost(a)redhat.com>,
"Gleb Natapov" <gleb(a)redhat.com>
Sent: Thursday, May 17, 2012 10:04:10 AM
Subject: Re: [Engine-devel] CPU Pinning @engine
On 05/17/2012 04:24 PM, Gary Kotton wrote:
> On 05/17/2012 02:42 PM, Doron Fediuck wrote:
>> Hi All,
>> Currently the VDSM has a CPU pinning hook.
>> We'd like to add better support of it into the engine itself.
>> Here's a design draft to cover it:
>> http://www.ovirt.org/wiki/Features/Design/cpu-pinning
>>
>> Please review and comment if needed.
> Hi,
> I have a number of comments:
> 1. Will the user have any indication for the maximum amount of
> vCPU's?
> 2. What happens if a VM is already configured with the same CPU
pin
> info? Will this be shared?
Yes
> 3. Would it possible to extend this to limit the MHz of CPU
that
> can be
> allocated to a VM?
No, that's not supported today in KVM. In the future we should use cgroups to provide
prioritization as part of the future SLA feature.
> 5. If the VM has more than one core, will each core have to be
> mapped?
yes
> 6. "similar to the existing hook Shahar wrote" - can
you please put
> a
> link the the hook that Shahar wrote. :) This will be helpful for
> those
> of us unfamiliar with it.
http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=tree;f=vdsm_hooks/pincpu;h=fd...
But basically it's the same syntax as libvirt uses today.
> 7. Why will live migration not be supported? What is the gap to
> have
> this type of support?
There's been disagreement here.
The argument against it is that if you have heterogeneous hardware then it might not
work.
eg. If I pin on vCPU 10-11 on host A and and host B only has 8 CPUs ....
I'd argue that if an admin is doing the pinning then it's up to him to make sure
he picks a sensible value
+1 on the above.
In addition, it should be nice to reveal the host cpu topology so the
user will be able to match the virtual one.
Getting the hyperthread topology is important factor as well.
Numa is not mentioned at all. It should be highly desirable to expose
the numa topology and add numa pinning using numactl.
Since you're refactoring this code, adding options for the new numda
daemon would be important too.
Another important factor is the ability to pin not only the vcpu
threads
but also to pin 'service threads' in the host, potential to other
physical cpus. Examples for such are the qemu io thread, vhost
threads, etc.
Regards,
Dor
> Thanks
> Gary
>> Thanks!
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel