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 -- To unsubscribe from this list: send the line "unsubscribe kvm-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
