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
--
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
