From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andi Kleen Subject: Re: [PATCH RFC V6 0/11] Paravirtualized ticketlocks Date: Sat, 31 Mar 2012 02:08:43 +0200 Message-ID: <20120331000843.GO17822@one.firstfloor.org> References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com> <4F7616F5.4070000@zytor.com> <20120330221836.GN17822@one.firstfloor.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: 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: Thomas Gleixner Cc: the arch/x86 maintainers , KVM , Konrad Rzeszutek Wilk , Peter Zijlstra , Stefano Stabellini , Raghavendra K T , LKML , Andi Kleen , Srivatsa Vaddagiri , Avi Kivity , Jeremy Fitzhardinge , "H. Peter Anvin" , Attilio Rao , Ingo Molnar , Virtualization , Linus Torvalds , Xen Devel , Stephan Diestelhorst List-Id: virtualization@lists.linuxfoundation.org On Sat, Mar 31, 2012 at 01:04:41AM +0200, Thomas "Kubys" Gleixner wrote: > On Sat, 31 Mar 2012, Andi Kleen wrote: > > > > So if a guest exits due to an external event it's easy to inspect the > > > state of that guest and avoid to schedule away when it was interrupted > > > in a spinlock held section. That guest/host shared state needs to be > > > > On a large system under high contention sleeping can perform surprisingly > > well. pthread mutexes have a tendency to beat kernel spinlocks there. > > So avoiding sleeping locks completely (that is what pv locks are > > essentially) is not necessarily that good. > > Care to back that up with numbers and proper trace evidence instead of > handwaving? E.g. my plumbers presentations on lock and mm scalability from last year has some graphs that show this very clearly, plus some additional data on the mutexes. This compares to the glibc futex locks, which perform much better than the kernel mutex locks on larger systems under higher contention Given your tone I will not supply an URL. I'm sure you can find it if you need it. -Andi -- ak@linux.intel.com -- Speaking for myself only. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757282Ab2CaAIu (ORCPT ); Fri, 30 Mar 2012 20:08:50 -0400 Received: from one.firstfloor.org ([213.235.205.2]:58601 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752621Ab2CaAIq (ORCPT ); Fri, 30 Mar 2012 20:08:46 -0400 Date: Sat, 31 Mar 2012 02:08:43 +0200 From: Andi Kleen To: Thomas Gleixner Cc: Andi Kleen , "H. Peter Anvin" , Raghavendra K T , Ingo Molnar , Linus Torvalds , Peter Zijlstra , the arch/x86 maintainers , LKML , Avi Kivity , Marcelo Tosatti , KVM , Xen Devel , Konrad Rzeszutek Wilk , Virtualization , Jeremy Fitzhardinge , Stephan Diestelhorst , Srivatsa Vaddagiri , Stefano Stabellini , Attilio Rao Subject: Re: [PATCH RFC V6 0/11] Paravirtualized ticketlocks Message-ID: <20120331000843.GO17822@one.firstfloor.org> References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com> <4F7616F5.4070000@zytor.com> <20120330221836.GN17822@one.firstfloor.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Mar 31, 2012 at 01:04:41AM +0200, Thomas "Kubys" Gleixner wrote: > On Sat, 31 Mar 2012, Andi Kleen wrote: > > > > So if a guest exits due to an external event it's easy to inspect the > > > state of that guest and avoid to schedule away when it was interrupted > > > in a spinlock held section. That guest/host shared state needs to be > > > > On a large system under high contention sleeping can perform surprisingly > > well. pthread mutexes have a tendency to beat kernel spinlocks there. > > So avoiding sleeping locks completely (that is what pv locks are > > essentially) is not necessarily that good. > > Care to back that up with numbers and proper trace evidence instead of > handwaving? E.g. my plumbers presentations on lock and mm scalability from last year has some graphs that show this very clearly, plus some additional data on the mutexes. This compares to the glibc futex locks, which perform much better than the kernel mutex locks on larger systems under higher contention Given your tone I will not supply an URL. I'm sure you can find it if you need it. -Andi -- ak@linux.intel.com -- Speaking for myself only.