17 May
2012
17 May
'12
5:38 p.m.
----- Original Message ----- > From: "Dor Laor" <dlaor@redhat.com> > To: gkotton@redhat.com > Cc: engine-devel@ovirt.org, "Eduardo Habkost" <ehabkost@redhat.com>, "Gleb Natapov" <gleb@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=fd7a1a85912504d6b0cc8ae4e8123d71bf3c2741;hb=HEAD 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@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >