Re: [RFC PATCH 0/2] irq destination caching prototype

[Gleb Natapov <gleb@redhat.com>]

On Mon, Aug 13, 2012 at 02:30:49PM +0300, Avi Kivity wrote:
> On 08/13/2012 02:12 PM, Gleb Natapov wrote:
> > On Mon, Aug 13, 2012 at 02:03:51PM +0300, Avi Kivity wrote:
> >> On 08/13/2012 02:01 PM, Gleb Natapov wrote:
> >> >> 
> >> >> Actually this is overkill.  Suppose we do an apicid->vcpu translation
> >> >> cache?  Then we retain O(1) behaviour, no need for a huge cache.
> >> >> 
> >> > Not sure I follow.
> >> 
> >> Unicast MSIs and IPIs can be speeded up by looking up the vcpu using the
> >> apic id, using a static lookup table (only changed when the guest
> >> updates apicid or a vcpu is inserted).
> >> 
> > To check that MSI/IPI is unicast you need to check a lot of things: delivery
> > mode, shorthand, dest mode, vector. In short everything but level. This
> > is exactly what kvm_irq_delivery_to_apic() is doing. Caching apicid->vcpu
> > is not enough, caching (delivery mode, shorthand, dest mode,
> > vector)->vcpu is enough and this is exactly what the patch does for irq
> > routing entries.
> 
> 
> apicid is checked in a loop, the others aren't. 
Along with dest_id.

>                                    apicid is
> unpredicatable; the others are.
What do you mean "unpredicatable"?

> 
> I think we should use apicid loopup exclusively.  It doesn't accelerate
> everything, but most things, and is common to all unicast interrupts
> except PIC (and we can also precompute the target vcpu for PIC, too).
> 
We can change kvm_irq_delivery_to_apic() to avoid the loop if interrupt
is physical, non broadcast, non low prio. Do whatever it does now
otherwise. You think we do not need cache in such case?

--
			Gleb.