Avi Kivity wrote:
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.
Just do a linear search of the CPUState list and be done with it. This
smells of premature optimization greatly. I would be amazed if walking
the CPUState list is ever on the fast path or will ever be. Really, if
you need to go from cpu_index => CPUState, it suggests you're doing
something wrong.
Regards,
Anthony Liguori
--
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
