Re: [Engine-devel] CPU Pinning @engine

----- Original Message ----- > From: "Dor Laor" <dlaor(a)redhat.com&gt; > To: gkotton(a)redhat.com > Cc: engine-devel(a)ovirt.org, "Eduardo Habkost" <ehabkost(a)redhat.com&gt;, "Gleb Natapov" <gleb(a)redhat.com&gt; > 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! >>