From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753017Ab2GPKIP (ORCPT ); Mon, 16 Jul 2012 06:08:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46118 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751290Ab2GPKIM (ORCPT ); Mon, 16 Jul 2012 06:08:12 -0400 Message-ID: <5003E7ED.2030701@redhat.com> Date: Mon, 16 Jul 2012 13:07:41 +0300 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: Raghavendra K T CC: "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , Marcelo Tosatti , Rik van Riel , Srikar , S390 , Carsten Otte , Christian Borntraeger , KVM , chegu vinod , "Andrew M. Theurer" , LKML , X86 , Gleb Natapov , linux390@de.ibm.com, Srivatsa Vaddagiri , Joerg Roedel Subject: Re: [PATCH RFC V4 3/3] kvm: Choose better candidate for directed yield References: <20120716082445.23477.15128.sendpatchset@codeblue.in.ibm.com> <20120716082529.23477.91096.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120716082529.23477.91096.sendpatchset@codeblue.in.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/16/2012 11:25 AM, Raghavendra K T wrote: > From: Raghavendra K T > > Currently, on a large vcpu guests, there is a high probability of > yielding to the same vcpu who had recently done a pause-loop exit or > cpu relax intercepted. Such a yield can lead to the vcpu spinning > again and hence degrade the performance. > > The patchset keeps track of the pause loop exit/cpu relax interception > and gives chance to a vcpu which: > (a) Has not done pause loop exit or cpu relax intercepted at all > (probably he is preempted lock-holder) > (b) Was skipped in last iteration because it did pause loop exit or > cpu relax intercepted, and probably has become eligible now > (next eligible lock holder) > > > +#ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT > +/* > + * Helper that checks whether a VCPU is eligible for directed yield. > + * Most eligible candidate to yield is decided by following heuristics: > + * > + * (a) VCPU which has not done pl-exit or cpu relax intercepted recently > + * (preempted lock holder), indicated by @cpu_relax_intercepted. > + * Set at the beiginning and cleared at the end of interception/PLE handler. > + * > + * (b) VCPU which has done pl-exit/ cpu relax intercepted but did not get > + * chance last time (mostly it has become eligible now since we have probably > + * yielded to lockholder in last iteration. This is done by toggling > + * @dy_eligible each time a VCPU checked for eligibility.) > + * > + * Yielding to a recently pl-exited/cpu relax intercepted VCPU before yielding > + * to preempted lock-holder could result in wrong VCPU selection and CPU > + * burning. Giving priority for a potential lock-holder increases lock > + * progress. > + */ > +bool kvm_vcpu_check_and_update_eligible(struct kvm_vcpu *vcpu) Predicates' names should give a hint as to what true and false returns mean. For example vcpu_eligible_for_directed_yield(). > +{ > + bool eligible; > + > + eligible = !vcpu->ple.cpu_relax_intercepted || > + (vcpu->ple.cpu_relax_intercepted && > + vcpu->ple.dy_eligible); > + > + if (vcpu->ple.cpu_relax_intercepted) > + vcpu->ple.dy_eligible = !vcpu->ple.dy_eligible; Probably should assign 'true', since the previous value is essentially random. > + > + return eligible; > +} You're accessing another vcpu's data structures without any locking. This is probably okay since we're not basing any life or death decisions on this, but a comment would be good to explain to readers that this has been considered and is okay (and why). -- error compiling committee.c: too many arguments to function