From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jes Sorensen Subject: Re: [patch] remove vcpu_info array v5 Date: Mon, 10 Nov 2008 16:47:51 +0100 Message-ID: <491857A7.1040909@sgi.com> References: <4909C00F.8050704@sgi.com> <49103812.1070104@redhat.com> <5d6222a80811040555q5be67439sbd38d94dfa25d8ad@mail.gmail.com> <49105C95.90809@redhat.com> <5d6222a80811040635j70c57efev1f3abc5096803b29@mail.gmail.com> <49105ED8.107@redhat.com> <4918376D.6060201@sgi.com> <491839CF.9060105@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Glauber Costa , Anthony Liguori , Hollis Blanchard , "kvm@vger.kernel.org" , "kvm-ia64@vger.kernel.org" To: Avi Kivity Return-path: Received: from relay2.sgi.com ([192.48.179.30]:46847 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752763AbYKJPr6 (ORCPT ); Mon, 10 Nov 2008 10:47:58 -0500 In-Reply-To: <491839CF.9060105@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: > Jes Sorensen wrote: >> >> Sorry, but this is riciculous. Please try and take a look at where the >> search is performed. It's *solely* in the ACPI hot plug code. > > There are other places we want a cpu from a cpu_index. Like the apic > code (admittedly that's only using the userspace apic, which is > non-default, but still). Hi Avi, Well this was based on what I ran into building the code. I didn't hit any issues where the apic code tried to do this. >> My patch gets rid of the pointless MAX_CPUS sized array, which doesn't >> buy us anything. In fact, most of the changes in my patch makes the >> code simpler, because it removes a stack of silly cases where qemu uses >> env->cpu_index to get into the array, just to hide CPUState from libkvm, >> just to have the callback in QEMU go from int vcpu back to CPUState. >> >> Lets just do it right and get rid of this silliness. > > I agree that vcpu_info should die. But we should still have a fast way > of getting a cpu from a cpu_index. I don't see a problem with a static > array of pointers, make it 16K in size if you want. Our real scaling > limits are much lower; they involve the big qemu lock and the single > iothread which will both limit scaling far below any static vcpu array. If we have reasons where we actually rely on the cpu number, and thats not counting end-user pretty-number-print concerns, then I found that we practically never use the cpu number. If we really use it a lot, I agree we need a fast way, I just didn't hit it in my builds. What did I miss? Jes