Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934532AbZAPAyV (ORCPT ); Thu, 15 Jan 2009 19:54:21 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756744AbZAPAx4 (ORCPT ); Thu, 15 Jan 2009 19:53:56 -0500 Received: from e5.ny.us.ibm.com ([32.97.182.145]:37708 "EHLO e5.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755919AbZAPAxx (ORCPT ); Thu, 15 Jan 2009 19:53:53 -0500 Date: Thu, 15 Jan 2009 16:53:51 -0800 From: "Paul E. McKenney" To: Linus Torvalds Cc: Ingo Molnar , Matthew Wilcox , Peter Zijlstra , Gregory Haskins , Andi Kleen , Chris Mason , Andrew Morton , Linux Kernel Mailing List , linux-fsdevel , linux-btrfs , Thomas Gleixner , Nick Piggin , Peter Morreale , Sven Dietrich , Dmitry Adamushko , Johannes Weiner Subject: Re: [GIT PULL] adaptive spinning mutexes Message-ID: <20090116005351.GD6763@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <1231867314.7141.16.camel@twins> <1231952436.14825.28.camel@laptop> <20090114183319.GA18630@elte.hu> <20090114184746.GA21334@elte.hu> <20090114192811.GA19691@elte.hu> <20090115174440.GF29283@parisc-linux.org> <20090115180844.GL22472@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1221 Lines: 29 On Thu, Jan 15, 2009 at 10:16:53AM -0800, Linus Torvalds wrote: > > > On Thu, 15 Jan 2009, Ingo Molnar wrote: > > > > btw., i think spin-mutexes have a design advantage here: in a lot of code > > areas it's quite difficult to use spinlocks - cannot allocate memory, > > cannot call any code that can sporadically block (but does not _normally_ > > block), etc. > > > > With mutexes those atomicity constraints go away - and the performance > > profile should now be quite close to that of spinlocks as well. > > Umm. Except if you wrote the code nicely and used spinlocks, you wouldn't > hold the lock over all those unnecessary and complex operations. > > IOW, if you do pre-allocation instead of holding a lock over the > allocation, you win. So yes, spin-mutexes makes it easier to write the > code, but it also makes it easier to just plain be lazy. In infrequently invoked code such as some error handling, lazy/simple can be a big win. Thanx, Paul -- 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/