From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [patch] remove vcpu_info array v5 Date: Mon, 10 Nov 2008 15:40:31 +0200 Message-ID: <491839CF.9060105@redhat.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> 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: Jes Sorensen Return-path: Received: from mx2.redhat.com ([66.187.237.31]:57208 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754913AbYKJNki (ORCPT ); Mon, 10 Nov 2008 08:40:38 -0500 In-Reply-To: <4918376D.6060201@sgi.com> Sender: kvm-owner@vger.kernel.org List-ID: 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). > realloc() is not an option, unless of course you are in favor of putting > a big lock around all access to such an array. > Right now qemu is single-threaded anyway. The only parallelism is when executing guest code. Of course we'll want to change that. > 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. -- error compiling committee.c: too many arguments to function