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

[Julien Grall <julien@xxxxxxx>]

Hi,

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?

> If we'd drop it, we'd also impact various vCPU-s in not really
> predictable ways.
Cheers,

--
Julien Grall