From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Woodhouse Subject: Re: [PATCH] use unfair spinlock when running on hypervisor. Date: Thu, 03 Jun 2010 12:06:39 +0100 Message-ID: <1275563199.2383.1873.camel@macbook.infradead.org> References: <20100601093515.GH24302@redhat.com> <87sk56ycka.fsf@basil.nowhere.org> <20100601162414.GA6191@redhat.com> <20100601163807.GA11880@basil.fritz.box> <4C053ACC.5020708@redhat.com> <4C05493F.1040107@third-harmonic.com> <20100601193659.GC11880@basil.fritz.box> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: john cooper , Avi Kivity , Gleb Natapov , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, hpa@zytor.com, mingo@elte.hu, npiggin@suse.de, tglx@linutronix.de, mtosatti@redhat.com, john cooper To: Andi Kleen Return-path: In-Reply-To: <20100601193659.GC11880@basil.fritz.box> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Tue, 2010-06-01 at 21:36 +0200, Andi Kleen wrote: > > Collecting the contention/usage statistics on a per spinlock > > basis seems complex. I believe a practical approximation > > to this are adaptive mutexes where upon hitting a spin > > time threshold, punt and let the scheduler reconcile fairness. > > That would probably work, except: how do you get the > adaptive spinlock into a paravirt op without slowing > down a standard kernel? It only ever comes into play in the case where the spinlock is contended anyway -- surely it shouldn't be _that_ much of a performance issue? See the way that ppc64 handles it -- on a machine with overcommitted virtual cpus, it will call __spin_yield (arch/powerpc/lib/locks.c) on contention, which may cause the virtual CPU to donate its hypervisor timeslice to the vCPU which is actually holding the lock in question. -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation