Re: [PATCH RFC] evtchn: add early-out to evtchn_move_pirqs()

[Jan Beulich <jbeulich@xxxxxxxx>]

On 11.04.2022 13:00, Julien Grall wrote:
> On 11/04/2022 11:45, Jan Beulich wrote:
>> On 11.04.2022 12:25, Julien Grall wrote:
>>> On 11/04/2022 07:13, Jan Beulich wrote:
>>>>>>>> --- a/xen/common/event_channel.c
>>>>>>>> +++ b/xen/common/event_channel.c
>>>>>>>> @@ -1559,6 +1559,16 @@ void evtchn_move_pirqs(struct vcpu *v)
>>>>>>>>          unsigned int port;
>>>>>>>>          struct evtchn *chn;
>>>>>>>>      
>>>>>>>> +    /*
>>>>>>>> +     * The work done below is an attempt to keep pIRQ-s on the pCPU-s 
>>>>>>>> that the
>>>>>>>> +     * vCPU-s they're to be delivered to run on. In order to limit 
>>>>>>>> lock
>>>>>>>> +     * contention, check for an empty list prior to acquiring the 
>>>>>>>> lock. In the
>>>>>>>> +     * worst case a pIRQ just bound to this vCPU will be delivered 
>>>>>>>> elsewhere
>>>>>>>> +     * until the vCPU is migrated (again) to another pCPU.
>>>>>>>> +     */
>>>>>>>
>>>>>>> AFAIU, the downside is another pCPU (and therefore vCPU) will get
>>>>>>> disturbed by the interrupt.
>>>>>>
>>>>>> But only rarely, i.e. in case a race would actually have occurred.
>>>>>
>>>>> Maybe I am too paranoid here. The other side of race is controlled by a
>>>>> domain. So wouldn't it be possible to increase how often the race is hit?
>>>>
>>>> Yes, of course - just to harm itself.
>>>
>>> Are you sure? Wouldn't this also harm the next vCPU running on the pCPU
>>> because it will get interrupted more often?
>>
>> Possibly, sure. But we don't make any promises here. And recall that
>> this optimization as a whole has been put under question in the past.
> 
> I don't remember this discussion. Do you have a pointer?

I'm sorry, but no, I don't have a pointer. This may even have been on irc.
All I recall (or at least I think I do) is that it was Andrew who raised
the concern.

Jan