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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

>> --- 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 we should revive "evtchn: convert 
> domain event lock to an r/w one"?

Not sure - the patch was rejected for there, overall, being too few
cases where read_lock() would suffice.

Jan