Re: [patch] remove vcpu_info array v5

[Jes Sorensen <jes@sgi.com>]

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