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 14:30:21 +0100 Message-ID: <4918376D.6060201@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> 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 netops-testserver-3-out.sgi.com ([192.48.171.28]:57443 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754926AbYKJNaZ (ORCPT ); Mon, 10 Nov 2008 08:30:25 -0500 In-Reply-To: <49105ED8.107@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: >> Yes, but I believe the whole point of jes patches is to remove those >> limits. >> > > So we could linear search huge lists? Or code hashes where arrays would > do? No, sir. > > An array of pointers statically sized at MAX_CPUS is fine. If you > insist, you can realloc() it on demand. 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. realloc() is not an option, unless of course you are in favor of putting a big lock around all access to such an array. 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. Jes