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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 08.04.2022 19:17, Julien Grall wrote:
> On 08/04/2022 13:25, Jan Beulich wrote:
>> On 08.04.2022 13:02, Julien Grall wrote:
>>> On 08/04/2022 08:16, Jan Beulich wrote:
>>>> See the code comment. The higher the rate of vCPU-s migrating across
>>>> pCPU-s, the less useful this attempted optimization actually is. With
>>>> credit2 the migration rate looks to be unduly high even on mostly idle
>>>> systems, and hence on large systems lock contention here isn't very
>>>> difficult to observe.
>>>
>>> "high" and "large" is quite vague. Do you have more details on where you
>>> observed this issue and the improvement after this patch?
>>
>> I have no data beyond the observation on the failed 4.12 osstest flights,
>> where I mentioned I would make such a patch and send out as RFC.
> 
> Ok. I think a pointer to the failed 4.12 osstest would be good here.

Done, albeit personally I don't think that's overly helpful.

>>>> --- 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. The important points are
- that correctness will be maintained, and
- that this is relevant for pass-through guests only (which are
  already not supposed to be entirely untrusted).

Jan