[Engine-devel] CPU Pinning @engine

[Doron Fediuck]

On 17/05/12 17:38, Andrew Cathrow wrote:
> 
> 
> ----- Original Message -----
>> From: "Dor Laor" <dlaor at redhat.com>
>> To: gkotton at redhat.com
>> Cc: engine-devel at ovirt.org, "Eduardo Habkost" <ehabkost at redhat.com>, "Gleb Natapov" <gleb at 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."