From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sasha Levin Subject: Re: APIC lookups Date: Fri, 02 Sep 2011 22:08:42 +0300 Message-ID: <1314990522.31676.30.camel@lappy> References: <1314986155.31676.22.camel@lappy> <20110902181323.GJ26451@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm To: Gleb Natapov Return-path: Received: from mail-wy0-f174.google.com ([74.125.82.174]:55055 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754342Ab1IBTIx (ORCPT ); Fri, 2 Sep 2011 15:08:53 -0400 Received: by wyh22 with SMTP id 22so2202295wyh.19 for ; Fri, 02 Sep 2011 12:08:52 -0700 (PDT) In-Reply-To: <20110902181323.GJ26451@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, 2011-09-02 at 21:13 +0300, Gleb Natapov wrote: > On Fri, Sep 02, 2011 at 08:55:55PM +0300, Sasha Levin wrote: > > Hi, > > > > I've noticed that kvm_irq_delivery_to_apic() is locating the destination > > APIC by running through kvm_for_each_vcpu() which becomes a scalability > > issue with a large number if vcpus. > > > > I'm thinking about speeding that up using a radix tree for lookups, and > > was wondering if it sounds right. > > > We have to call kvm_apic_match_dest() on each apic to see if it should > get the message. Single message can be sent to more than one apic. It is > likely possible to optimize common case of physical addressing fixed > destination, but then just use array of 256 elements, no need for a tree. I think it's also possible to handle it for logical addressing as well, instead of a simple compare we just need to go through all the IDs that would 'and' with the dest. > Do you see this function in profiling? I was running profiling to see which functions get much slower during regular operation (not boot) when you run with large amount of vcpus, and this was one of them. Though this is probably due to the method we use to find lowest priority and not the lookups themselves. -- Sasha.