[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH 3/3] qemu: Prohibit chaning affinity of domain process if placement is 'auto'



On 10/24/2012 03:45 PM, Osier Yang wrote:
> On 2012年10月24日 21:38, Martin Kletzander wrote:
>> On 10/24/2012 12:00 PM, Osier Yang wrote:
>>> On one hand, numad probably will manage the affinity of domain process
>>> dynamically in future. On the other hand, even numad won't manage it,
>>
>> s/even/even if/
>>
>>> it still could confusion. Let's make things simpler enough to avoid
>>
>> s/could/could cause/
>>
>>> the lair for now.
>>> ---
>>>   src/qemu/qemu_driver.c |    7 +++++++
>>>   1 files changed, 7 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
>>> index 8af316f..254f191 100644
>>> --- a/src/qemu/qemu_driver.c
>>> +++ b/src/qemu/qemu_driver.c
>>> @@ -4204,6 +4204,13 @@ qemudDomainPinEmulator(virDomainPtr dom,
>>>           goto cleanup;
>>>       }
>>>
>>> +    if (vm->def->placement_mode ==
>>> VIR_DOMAIN_CPU_PLACEMENT_MODE_AUTO) {
>>> +        virReportError(VIR_ERR_OPERATION_INVALID, "%s",
>>> +                       _("Changing affinity for emulator thread
>>> dynamically "
>>> +                         "is not allowed when CPU placement is
>>> 'auto'"));
>>> +        goto cleanup;
>>> +    }
>>> +
>>>       if (virDomainLiveConfigHelperMethod(driver->caps, vm,&flags,
>>>                                           &persistentDef)<  0)
>>>           goto cleanup;
>>>
>>
>> We should unify if the vcpu pinning is only meant for starting the
>> domain or if it's mandatory for the whole time domain is running.  It is
>> possible now to have auto placement and pin the vcpus while the domain
>> is running.
>>
>> If we want to disable it for emulator threads, we should also do it for
>> VCPU threads.
> 
> IMO no need to disable for vCPU threads, as "auto" placement only
> cares about the affinity of domain process, it might imply we should
> change that, but now it is that.
> 
> However, then decision whether we should do it at all
>> should not be made by me.  Anyone else has an opinion on that?
>>
>> Martin
> 

Of course, sorry, my bad.  ACK, of course.

Martin


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]