On 06/11/2010 05:25 AM, Marcelo Tosatti wrote:
The following patch implements a simple busy-spin detector. It considers
a vcpu as busy-spinning if there are two consecutive exits due to
external interrupt on the same RIP, and sleeps for 100us in that case.
It is very likely that if the vcpu is making progress it will either
exit for other reasons or change RIP.
The percentage numbers below represent improvement in kernel build
time in comparison with mainline (RHEL 5.4 guest).
make -j16, 8 cpu host:
smp 16: 3%
smp 18: 10%
smp 32: 14%
smp 4, make -j4, pinned to 2 cpus:
4%
smp 8, make -j8, pinned to 2 cpus:
5%
The big problem here is not in the patch itself, but in
kvm_vcpu_on_spin(). An un-overcommitted guest will trigger this on long
spinlocks and go to sleep, and if the lock is released while we're still
sleeping, we lose performance.
@@ -4654,6 +4665,8 @@ static int vcpu_enter_guest(struct kvm_v
kvm_lapic_sync_from_vapic(vcpu);
r = kvm_x86_ops->handle_exit(vcpu);
+ if (r == 1)
+ vcpu->arch.last_rip = ~(0UL);
out:
return r;
}
!= 2, no?
It's a little ugly to overload the return code like that. Perhaps:
+ vcpu->arch.save_last_rip = vcpu->arch.last_rip
+ vcpu->arch.last_rip = ~0UL;
r = kvm_x86_ops->handle_exit(vcpu);
And kvm_detect_spin() can restore last_rip.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
