From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [RFC PATCH 0/2] irq destination caching prototype Date: Mon, 13 Aug 2012 14:01:08 +0300 Message-ID: <20120813110108.GX3341@redhat.com> References: <1344849408-2697-1-git-send-email-gleb@redhat.com> <5028CAA9.8070807@redhat.com> <20120813101246.GA16147@redhat.com> <20120813101608.GS3341@redhat.com> <5028D52D.9050104@redhat.com> <20120813102402.GT3341@redhat.com> <5028D788.3070006@redhat.com> <20120813103845.GA16300@redhat.com> <5028DDCD.1090205@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Michael S. Tsirkin" , kvm@vger.kernel.org, Jan Kiszka To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:38718 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751309Ab2HMLBK (ORCPT ); Mon, 13 Aug 2012 07:01:10 -0400 Content-Disposition: inline In-Reply-To: <5028DDCD.1090205@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Aug 13, 2012 at 01:58:21PM +0300, Avi Kivity wrote: > On 08/13/2012 01:38 PM, Michael S. Tsirkin wrote: > > On Mon, Aug 13, 2012 at 01:31:36PM +0300, Avi Kivity wrote: > >> On 08/13/2012 01:24 PM, Gleb Natapov wrote: > >> > On Mon, Aug 13, 2012 at 01:21:33PM +0300, Avi Kivity wrote: > >> >> 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. > >> >> > >> > OK. Then it should be big enough to not do it frequently. > >> > >> Should be sized N * vcpus, where N is several dozen (generous amount of > >> non-device vectors, though multicast will break it since it's > >> essentially random). > > > > KVM_MAX_VCPUS is 256 multiply by what? 50? this is 10K already. > > You can not allocate that much in a single chunk, right? > > 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. -- Gleb.