From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC PATCH 0/2] irq destination caching prototype Date: Mon, 13 Aug 2012 13:21:33 +0300 Message-ID: <5028D52D.9050104@redhat.com> References: <1344849408-2697-1-git-send-email-gleb@redhat.com> <5028CAA9.8070807@redhat.com> <20120813101246.GA16147@redhat.com> <20120813101608.GS3341@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Michael S. Tsirkin" , kvm@vger.kernel.org, Jan Kiszka To: Gleb Natapov Return-path: Received: from mx1.redhat.com ([209.132.183.28]:55138 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751456Ab2HMKVj (ORCPT ); Mon, 13 Aug 2012 06:21:39 -0400 In-Reply-To: <20120813101608.GS3341@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 08/13/2012 01:16 PM, Gleb Natapov wrote: > On Mon, Aug 13, 2012 at 01:12:46PM +0300, Michael S. Tsirkin wrote: >> On Mon, Aug 13, 2012 at 12:36:41PM +0300, Avi Kivity wrote: >> > On 08/13/2012 12:16 PM, Gleb Natapov wrote: >> > > Here is a quick prototype of what we discussed yesterday. This one >> > > caches only MSI interrupts for now. The obvious problem is that not >> > > all interrupts (namely IPIs and MSIs using KVM_CAP_SIGNAL_MSI) use irq >> > > routing table, so they cannot be cached. >> > >> > We can have a small rcu-managed hash table to look those up. >> >> Yes but how small? We probably need at least one entry >> per vcpu, no? >> > One entry? We will spend more time managing it than injecting interrupts > :) ideally we need entry for each IPI sent and for each potential MSI > from userspace. What happens when hash table is full? Drop the entire cache. > We stop caching or > invalidate old entries? If later then cache can go valid->invalid which > may complicate the code. > We can drop the entire cache via rcu freeing. In fact we can have a closed hash allocated as a single blob, easy to manage. -- error compiling committee.c: too many arguments to function