Re: [patch] remove vcpu_info array v5

Avi Kivity
2008-11-10T13:40:38Z

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