On 10/31/2012 07:11 PM, Avi Kivity wrote:
On 10/31/2012 03:15 PM, Raghavendra K T wrote:
On 10/31/2012 06:11 PM, Raghavendra K T wrote:
On 10/31/2012 06:08 PM, Avi Kivity wrote:
On 10/29/2012 04:07 PM, Raghavendra K T wrote:
From: Raghavendra K T <raghavendra.kt@xxxxxxxxxxxxxxxxxx>
Also we do not update last boosted vcpu in failure cases.
#endif
+
void kvm_vcpu_on_spin(struct kvm_vcpu *me)
{
struct kvm *kvm = me->kvm;
@@ -1727,11 +1727,12 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
continue;
if (!kvm_vcpu_eligible_for_directed_yield(vcpu))
continue;
- if (kvm_vcpu_yield_to(vcpu)) {
+
+ yielded = kvm_vcpu_yield_to(vcpu);
+ if (yielded > 0)
kvm->last_boosted_vcpu = i;
- yielded = 1;
+ if (yielded)
break;
- }
}
If yielded == -ESRCH, should we not try to yield to another vcpu?
Yes. plan is to abort the iteration. since it means we are mostly
undercommitted.
Sorry if it was ambiguous. I wanted to say we do not want to continue
yield to another vcpu..
Why not? We found that this particular vcpu is running and therefore
likely not a lock holder. That says nothing about other vcpus. The
next in line might be runnable-but-not-running on another runqueue.
Agree that next in the line might be runnable-not-running. But here we
are optimistic that, that is not the case and we save time by
returning back instead of iterating, thinking we are mostly in
undercommitted case and each vcpu has dedicated cpu.
Probably an alternative we have here is to look for say 2-3 successive
failures before breaking out?
--
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
