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

Osier Yang jyang at redhat.com
Wed Oct 24 14:43:08 UTC 2012


On 2012年10月24日 21:54, Martin Kletzander wrote:
> 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.
>

Thanks for the reviewing, since the patches are not likely
to break things. I pushed them now.

Regards,
Osier




More information about the libvir-list mailing list