17 May
2012
17 May
'12
5:58 p.m.
On 17/05/12 17:38, Andrew Cathrow wrote: > > > ----- 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! >>> +1 on Andrew's answers. Just want to add a general comment- CPU tuning can evolve into something which is much bigger. I choose to start with a humble pinning support, which I know is already being used today using vdsm hook. Having it in the engine (even in a basic mode) will be more friendly and helpful to many users. Going forward we have a lot of grounds to cover in this area, including NUMA and other exciting features, which we'll gradually introduce as the community allows. -- /d "All computers wait at the same speed."