From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH V2 RFC 2/3] kvm: Handle yield_to failure return code for potential undercommit case Date: Wed, 31 Oct 2012 15:41:06 +0200 Message-ID: <50912A72.6050307@redhat.com> References: <20121029140621.15448.92083.sendpatchset@codeblue> <20121029140702.15448.56932.sendpatchset@codeblue> <50911BC3.6080305@redhat.com> <50911C7D.5080307@linux.vnet.ibm.com> <50912463.3040201@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Peter Zijlstra , "H. Peter Anvin" , Marcelo Tosatti , Ingo Molnar , Rik van Riel , Srikar , "Nikunj A. Dadhania" , KVM , Jiannan Ouyang , Chegu Vinod , "Andrew M. Theurer" , LKML , Srivatsa Vaddagiri , Gleb Natapov , Andrew Jones To: Raghavendra K T Return-path: In-Reply-To: <50912463.3040201@linux.vnet.ibm.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 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 >>>> >>>> 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. -- error compiling committee.c: too many arguments to function