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
