Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762759AbZANPof (ORCPT ); Wed, 14 Jan 2009 10:44:35 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752179AbZANPoX (ORCPT ); Wed, 14 Jan 2009 10:44:23 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:54039 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751268AbZANPoU (ORCPT ); Wed, 14 Jan 2009 10:44:20 -0500 Date: Wed, 14 Jan 2009 07:43:02 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Ingo Molnar cc: Chris Mason , Peter Zijlstra , "Paul E. McKenney" , Gregory Haskins , Matthew Wilcox , Andi Kleen , Andrew Morton , Linux Kernel Mailing List , linux-fsdevel , linux-btrfs , Thomas Gleixner , Nick Piggin , Peter Morreale , Sven Dietrich , Dmitry Adamushko Subject: Re: [PATCH -v9][RFC] mutex: implement adaptive spinning In-Reply-To: <20090114112158.GA8625@elte.hu> Message-ID: References: <1231774622.4371.96.camel@laptop> <1231859742.442.128.camel@twins> <1231863710.7141.3.camel@twins> <1231864854.7141.8.camel@twins> <1231867314.7141.16.camel@twins> <1231901899.1709.18.camel@think.oraclecorp.com> <20090114112158.GA8625@elte.hu> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1423 Lines: 40 On Wed, 14 Jan 2009, Ingo Molnar wrote: > > * Chris Mason wrote: > > > v10 is better that not spinning, but its in the 5-10% range. So, I've > > been trying to find ways to close the gap, just to understand exactly > > where it is different. > > > > If I take out: > > /* > > * If there are pending waiters, join them. > > */ > > if (!list_empty(&lock->wait_list)) > > break; > > > > > > v10 pops dbench 50 up to 1800MB/s. The other tests soundly beat my > > spinning and aren't less fair. But clearly this isn't a good solution. > > i think since we already decided that it's ok to be somewhat unfair (_all_ > batching constructs introduce unfairness, so the question is never 'should > we?' but 'by how much?'), we should just take this out and enjoy the speed Yeah, let's just do it. It's going to be unfair, but let's see if the unfairness is going to actually be noticeable in real life. I suspect it isn't, and if it is, we can look at it again and see if there are other approaches. If it makes _that_ much of a difference on dbench, it's worth being unfair even if it's just for some dubious benchmark. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/