From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC][PATCH 12/45] msi: Introduce MSIRoutingCache Date: Mon, 17 Oct 2011 14:17:38 +0200 Message-ID: <4E9C1CE2.8070808@redhat.com> References: <4E9C0C42.60201@redhat.com> <4E9C0F5C.8000602@siemens.com> <4E9C109B.4070207@redhat.com> <4E9C121C.8050309@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alex Williamson , Marcelo Tosatti , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , "Michael S. Tsirkin" To: Jan Kiszka Return-path: In-Reply-To: <4E9C121C.8050309@siemens.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org On 10/17/2011 01:31 PM, Jan Kiszka wrote: > > > > Just to make sure I understand this completely: a hash table indexed by > > MSIMessage in kvm code would avoid this? You'd just allocate on demand > > when seeing a new MSIMessage and free on an LRU basis, avoiding pinned > > entries. > > > > I'm not advocating this (yet), just want to understand the tradeoffs. > > Practically, that may work. I just wanted to avoid searching. And for > static routes (irqfd, device assigment) you still need caches anyway, so > I decided to use them consistently. Okay. Even if we do decide to go for transparent caches, it should be done after this is merged, to avoid excessive churn. -- error compiling committee.c: too many arguments to function