[Engine-devel] CPU Pinning @engine

Tue May 22 14:05:33 UTC 2012

On 21/05/12 12:40, Doron Fediuck wrote:
> On 21/05/12 12:18, Yaniv Kaul wrote:
>> On 05/21/2012 11:53 AM, Doron Fediuck wrote:
>>> On 21/05/12 11:16, Yaniv Kaul wrote:
>>>> On 05/21/2012 11:08 AM, Doron Fediuck wrote:
>>>>> On 21/05/12 11:01, Dor Laor wrote:
>>>>>> On 05/21/2012 10:58 AM, Doron Fediuck wrote:
>>>>>>> On 21/05/12 01:45, Andrew Cathrow wrote:
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Doron Fediuck"<dfediuck at redhat.com>
>>>>>>>>> To: dlaor at redhat.com
>>>>>>>>> Cc: engine-devel at ovirt.org
>>>>>>>>> Sent: Sunday, May 20, 2012 5:49:08 PM
>>>>>>>>> Subject: Re: [Engine-devel] CPU Pinning @engine
>>>>>>>>>
>>>>>>>>> On 20/05/12 21:41, Dor Laor wrote:
>>>>>>>>>> On 05/17/2012 11:15 PM, Doron Fediuck wrote:
>>>>>>>>>>> On 17/05/12 20:28, Ayal Baron wrote:
>>>>>>>>>>>> "Live migration will not be supported for such VM's."
>>>>>>>>>>>>
>>>>>>>>>>>> Migration will work on homogeneous clusters so this should not be
>>>>>>>>>>>> enforced (not limited to VMs which are pinned to host) just give
>>>>>>>>>>>> a warning.
>>>>>>>>>>>>
>>>>>>>>>>> I agree, but if we wish to ping vCPUx to pCPUy in host a, we
>>>>>>>>>>> cannot ensure to have the same in host b,
>>>>>>>>>>> since it may have pCPUy too busy, so performance will degrade.
>>>>>>>>>>> Also, I hope you saw my general comment
>>>>>>>>>> Performance may degrade on any migration to loaded host regardless
>>>>>>>>>> of pinning.
>>>>>>>>>>
>>>>>>>>>> There is not need to forbid migration. Instead, the SLA assurance
>>>>>>>>>> policy should verify the dedicated resources and match the target
>>>>>>>>>> w/ the guarantee and decide according to this.
>>>>>>>>>>
>>>>>>>>> Thanks for the input.
>>>>>>>>> We may start with migration blocked in a configurable manner, so
>>>>>>>>> people who wish migrate to work
>>>>>>>>> will simply set the relevant configuration key.
>>>>>>>>> As for looking for a matched CPU, will add it as p2.
>>>>>>>> We shouldn't block migration
>>>>>>>> If a user wants to not migrate a cpu pinned VM then let them use the non-migratable flag in the UI.
>>>>>>>>
>>>>>>> We're not blocking migration, we're allowing pinning (for now) only for non-migrative VM's.
>>>>>>> For p2 we'll verify destination host has the relevant pinning capacity, which will allow
>>>>>>> pinning for migrative VM's as well.
>>>>>> IMHO the order should be the opposite - if the user likes to migrate a pinned VM, let him (you can pop some message if you like).
>>>>> I'll check it with UI guys (AFAIK engine UI has no pop-ups).
>>>>> Also, I prefer safe than sorry. So start with a safe working pinning for pinned-to-host VMs, and then push the envelope.
>>>> Safe is letting the user migrate. It may or may not succeed (I'd worry it may put a host into Error state - I hope we've removed this state).
>>> This is a pure speculation. If I'm pinning a specific VM to a specific host, and its vCPUS into specific pCPUs,
>>> how can live migration be considered a safe thing? If I pinned to host, this is a violation of my request. Now, let's say
>>> I didn't pin to host, but I ask for specific vCPUS pinning into specific pCPUs. For now, there's no guarantee the destination
>>> host will have a relevant CPU capacity (maybe even topology), so CPU pinning may not work, which is also a violation of
>>> my request. Is live migration really the safe thing to do here??? Why not alert me so I could manually migrate to where I think
>>> is better?
>>> Having that said, I'm reminding you the somewhere earlier in this thread I wrote we'll make the constraint of cpu pinning
>>> allowed only on pinned-to-host VMs configurable, so people who wish to walk on wild side, can give it a go.
>>
>> I think the consensus of the thread is that you should allow pin vCPUs to pCPUs even if the VM is not pinned to host.
>> If the user wants to ensure it will not migrate, he should mark the VM as non migratable.
>> Otherwise, it may migrate, and will succeed - if it can meet  the same pinning requirements on the destination, or fail - and then no harm done.
>> If migration succeeds without meeting the pinning requirements on the destination, I see this as a libvirt bug.
>> Y.
> Basically I already said cpu-pin is allowed for migrative VM's once configuring it.
> So basically what you're saying is that if such migration works, while loosing cpu-pin, it's a libvirt bug.
> I can live with that. I hope Daniel agrees with you.
> 

Design updated, so pinning is not blocked, unless user will block it (pin to host, etc).
UI will be updated shortly. Please review-
http://www.ovirt.org/wiki/Features/Design/cpu-pinning

>>
>>>
>>>> Sorry is when you wish you had done so initially.  ;-)
>>> In this case, I disagree as this is configurable.
>>>
>>>> Y.
>>>>
>>>>
>>>>>>>>>>> about starting with a humble solution and gradually improving. In
>>>>>>>>>>> this context (auto)numa can help us,
>>>>>>>>>>> so we better do numa than handle migration for basic mode, risking
>>>>>>>>>>> performance issues.
>>>>>>>>>>>
>>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>>> From: "Doron Fediuck"<dfediuck at redhat.com>
>>>>>>>>>>>>> To: engine-devel at ovirt.org
>>>>>>>>>>>>> Sent: Thursday, May 17, 2012 2:42:46 PM
>>>>>>>>>>>>> Subject: [Engine-devel] CPU Pinning @engine
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>
>>>>>>>>>>>>> /d
>>>>>>>>>>>>>
>>>>>>>>>>>>> Never say "OOPS!" always say "Ah, Interesting!"
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Engine-devel mailing list
>>>>>>>>>>>>> Engine-devel at ovirt.org
>>>>>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Engine-devel mailing list
>>>>>>>>>>>> Engine-devel at ovirt.org
>>>>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>> -- 
>>>>>>>>>
>>>>>>>>> /d
>>>>>>>>>
>>>>>>>>> Never say "OOPS!" always say "Ah, Interesting!"
>>>>>>>>> _______________________________________________
>>>>>>>>> Engine-devel mailing list
>>>>>>>>> Engine-devel at ovirt.org
>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>>
>>>
>>
> 
> 

-- 

/d

"Hi, my name is Any Key. Please don't hit me!"