On 08/13/2012 02:41 PM, Gleb Natapov wrote: > 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. Right, that is converted to a lookup. > >> apicid is >> unpredicatable; the others are. > What do you mean "unpredicatable"? In terms of branch prediction. We can't tell when the loop will terminate. On the other hand most IPIs are likely to have the same delivery mode/shorthand/dest mode. (not entirely true, we can expect a mix of broadcast/unicast/multicast) > >> >> 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? We can also loop in logical, since the loop is limited to 16 (in x2apic mode); it doesn't scale with the number of vcpus. We need a lookup table of cluster id -> array of 16 vcpus. Broadcast obviously must loop, no cache can help. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
