From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [RFC PATCH 0/2] irq destination caching prototype Date: Mon, 13 Aug 2012 15:59:52 +0300 Message-ID: <20120813125952.GD16801@redhat.com> References: <5028D52D.9050104@redhat.com> <20120813102402.GT3341@redhat.com> <5028D788.3070006@redhat.com> <20120813103845.GA16300@redhat.com> <5028DDCD.1090205@redhat.com> <20120813110108.GX3341@redhat.com> <5028DF17.2050008@redhat.com> <20120813111241.GY3341@redhat.com> <5028E569.9050807@redhat.com> <20120813114147.GA3341@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , kvm@vger.kernel.org, Jan Kiszka To: Gleb Natapov Return-path: Received: from mx1.redhat.com ([209.132.183.28]:5648 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750975Ab2HMM6s (ORCPT ); Mon, 13 Aug 2012 08:58:48 -0400 Content-Disposition: inline In-Reply-To: <20120813114147.GA3341@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Aug 13, 2012 at 02:41:47PM +0300, 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. > > > 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, logical is also not too hard. need two extra tables for cluster/non cluster. > non broadcast, non low prio. Do whatever it does now > otherwise. You think we do not need cache in such case? > > -- > Gleb.