lkml.org 
[lkml]   [2012]   [Oct]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH V2 RFC 2/3] kvm: Handle yield_to failure return code for potential undercommit case
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@linux.vnet.ibm.com>
>>>>>
>>>>> 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?



\
 
 \ /
  Last update: 2012-11-01 03:41    [W:0.075 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site