Re: [PATCH v2] x86/apic/x2apic: Share IRQ vector between cluster members only when no cpumask is specified

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

On 08/28/2017 11:41 AM, Jan Beulich wrote:
>>>> On 28.08.17 at 16:35, <boris.ostrovsky@oracle.com> wrote:
>> On 08/28/2017 03:38 AM, Jan Beulich wrote:
>>>>> And finally I continue to be not really happy about the change as
>>>>> a whole. Despite what was discussed on v1, I'm concerned of the
>>>>> effects of this on hosts _not_ suffering from vector shortage.
>>>>> Could you live with the new behavior requiring a command line
>>>>> option to enable?
>>>> I can add something like 'apic_share_vectors', defaulting to true,
>>>> although it will not be useful in case of a hotplug. Defaulting to false?
>>> Along the lines of the above plus our desire to limit the number
>>> of top level options, how about "apic=isolate-vectors"?
>>>
>>> Also I don't understand your reference to hotplug, nor why you
>>> suggest two opposite default values.
>> Not two, just one --- not share vectors by default.
>>
>> As for hotplug, I was thinking of a case where a system is successfully
>> booted with shared vectors but then a device is added and we fail to
>> find enough free vectors. So the administrator would need to know in
>> advance whether a new card might be coming in.
>>
>> When defaulting to false (as in apic_share_vectors=false) if the
>> administrator decides to set it to true then he would be in some sense
>> explicitly agreeing to never plug anything in (or at least to tolerate
>> such a failure).
> Ah, I see. But imo the default ought to be current behavior.
>
>>> But finally, you agreeing to a command line option here makes
>>> me come back to an earlier suggestion: Didn't we agree that
>>> "x2apic_phys" would be sufficient to eliminate the issue? In which
>>> case no patch would be needed at all.
>> x2apic_phys means that we never share vectors. With 'isolate-vectors'
>> option we are still able to share them if the mask is explicitly specified.
> Well, aiui your primary goal is to address the vector shortage. For
> that you don't need the new option, you can get away with the
> existing one.


I don't have any numbers to prove (or disprove) that not sharing vectors
during boot but possibly sharing them later improves performance so yes,
x2apic_phys is a possible solution. Especially if with this (modified)
patch we'd default to original cluster mode behavior as you are suggesting.

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel