From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH RFC v5 4/8] pvqspinlock, x86: Allow unfair spinlock in a real PV environment Date: Mon, 03 Mar 2014 11:55:41 +0100 Message-ID: <53145FAD.3020905@redhat.com> References: <1393427668-60228-1-git-send-email-Waiman.Long@hp.com> <1393427668-60228-5-git-send-email-Waiman.Long@hp.com> <20140226170734.GB20775@phenom.dumpdata.com> <5310C21F.7000809@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5310C21F.7000809@hp.com> 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: Waiman Long , Konrad Rzeszutek Wilk Cc: Jeremy Fitzhardinge , Raghavendra K T , Peter Zijlstra , virtualization@lists.linux-foundation.org, Andi Kleen , "H. Peter Anvin" , Michel Lespinasse , Alok Kataria , linux-arch@vger.kernel.org, x86@kernel.org, Ingo Molnar , Scott J Norton , xen-devel@lists.xenproject.org, "Paul E. McKenney" , Alexander Fyodorov , Rik van Riel , Arnd Bergmann , Daniel J Blueman , Oleg Nesterov , Steven Rostedt , Chris Wright , George Spelvin , Thomas Gleixner , Aswin Chandramouleeswaran , Cheg List-Id: linux-arch.vger.kernel.org Il 28/02/2014 18:06, Waiman Long ha scritto: > On 02/26/2014 12:07 PM, Konrad Rzeszutek Wilk wrote: >> On Wed, Feb 26, 2014 at 10:14:24AM -0500, Waiman Long wrote: >>> Locking is always an issue in a virtualized environment as the virtual >>> CPU that is waiting on a lock may get scheduled out and hence block >>> any progress in lock acquisition even when the lock has been freed. >>> >>> One solution to this problem is to allow unfair lock in a >>> para-virtualized environment. In this case, a new lock acquirer can >>> come and steal the lock if the next-in-line CPU to get the lock is >>> scheduled out. Unfair lock in a native environment is generally not a >> Hmm, how do you know if the 'next-in-line CPU' is scheduled out? As >> in the hypervisor knows - but you as a guest might have no idea >> of it. > > I use a heart-beat counter to see if the other side responses within a > certain time limit. If not, I assume it has been scheduled out probably > due to PLE. PLE is unnecessary if you have "true" pv spinlocks where the next-in-line schedules itself out with a hypercall (Xen) or hlt instruction (KVM). Set a bit in the qspinlock before going to sleep, and the lock owner will know that it needs to kick the next-in-line. I think there is no need for the unfair lock bits. 1-2% is a pretty large hit. Paolo