Re: [patch] remove vcpu_info array v5

[Avi Kivity <avi@redhat.com>]

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