From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rik van Riel Subject: Re: [PATCH v15 16/16] unfair qspinlock: a queue based unfair lock Date: Thu, 09 Apr 2015 10:30:02 -0400 Message-ID: <55268CEA.70303@redhat.com> References: <1428517939-27968-1-git-send-email-Waiman.Long@hp.com> <20150409070146.GL27490@worktop.programming.kicks-ass.net> <55267BA8.9060009@redhat.com> <20150409141348.GX5029@twins.programming.kicks-ass.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150409141348.GX5029@twins.programming.kicks-ass.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: Peter Zijlstra Cc: Waiman Long , linux-arch@vger.kernel.org, Raghavendra K T , Oleg Nesterov , kvm@vger.kernel.org, Konrad Rzeszutek Wilk , Daniel J Blueman , x86@kernel.org, Paolo Bonzini , linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, Scott J Norton , Ingo Molnar , David Vrabel , "H. Peter Anvin" , xen-devel@lists.xenproject.org, Thomas Gleixner , "Paul E. McKenney" , Linus Torvalds , Boris Ostrovsky , Douglas Hatch List-Id: virtualization@lists.linuxfoundation.org On 04/09/2015 10:13 AM, Peter Zijlstra wrote: > On Thu, Apr 09, 2015 at 09:16:24AM -0400, Rik van Riel wrote: >> On 04/09/2015 03:01 AM, Peter Zijlstra wrote: >>> On Wed, Apr 08, 2015 at 02:32:19PM -0400, Waiman Long wrote: >>>> For a virtual guest with the qspinlock patch, a simple unfair byte lock >>>> will be used if PV spinlock is not configured in or the hypervisor >>>> isn't either KVM or Xen. The byte lock works fine with small guest >>>> of just a few vCPUs. On a much larger guest, however, byte lock can >>>> have serious performance problem. >>> >>> Who cares? >> >> There are some people out there running guests with dozens >> of vCPUs. If the code exists to make those setups run better, >> is there a good reason not to use it? > > Well use paravirt, !paravirt stuff sucks performance wise anyhow. > > The question really is: is the added complexity worth the maintenance > burden. And I'm just not convinced !paravirt virt is a performance > critical target. Fair enough.