Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761322AbZAHQ7Y (ORCPT ); Thu, 8 Jan 2009 11:59:24 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751692AbZAHQ7M (ORCPT ); Thu, 8 Jan 2009 11:59:12 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:55336 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751239AbZAHQ7L (ORCPT ); Thu, 8 Jan 2009 11:59:11 -0500 Date: Thu, 8 Jan 2009 08:58:06 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Peter Zijlstra cc: Ingo Molnar , Steven Rostedt , paulmck@linux.vnet.ibm.com, Gregory Haskins , Matthew Wilcox , Andi Kleen , Chris Mason , Andrew Morton , Linux Kernel Mailing List , linux-fsdevel , linux-btrfs , Thomas Gleixner , Nick Piggin , Peter Morreale , Sven Dietrich Subject: Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning In-Reply-To: <1231426014.11687.456.camel@twins> Message-ID: References: <1231347442.11687.344.camel@twins> <1231365115.11687.361.camel@twins> <1231366716.11687.377.camel@twins> <1231408718.11687.400.camel@twins> <20090108141808.GC11629@elte.hu> <1231426014.11687.456.camel@twins> 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: 1416 Lines: 37 Ok, I've gone through -v7, and I'm sure you're all shocked to hear it, but I have no complaints. Except that you dropped all the good commit commentary you had earlier ;) The patch looks pretty good (except for the big "#if 0" block in mutex-debug.c that I hope gets fixed, but I can't even really claim that I can be bothered), the locking looks fine (ie no locking at all), and the numbers seem pretty convinving. Oh, and I think the open-coded atomic_cmpxchg(count, 1, 0) == 1 could possibly just be replaced with a simple __mutex_fastpath_trylock(). I dunno. IOW, I'd actually like to take it, but let's give it at least a day or two. Do people have any concerns? And as far as I'm concerned, the nice part about not having any locking there is that now the spinning has no impact what-so-ever on the rest of the mutex logic. There are no subtleties about any of that - it's literally about falling back to a (fairly educated) "try a few trylocks if you fail". So it _looks_ pretty robust. I don't think there should be any subtle interactions with anything else. If the old mutexes worked, then the spinning should work. Discussion? 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/