Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755547AbZAHHLW (ORCPT ); Thu, 8 Jan 2009 02:11:22 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752542AbZAHHLK (ORCPT ); Thu, 8 Jan 2009 02:11:10 -0500 Received: from casper.infradead.org ([85.118.1.10]:60013 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752351AbZAHHLI (ORCPT ); Thu, 8 Jan 2009 02:11:08 -0500 Subject: Re: [PATCH -v5][RFC]: mutex: implement adaptive spinning From: Peter Zijlstra To: Linus Torvalds Cc: Steven Rostedt , Gregory Haskins , Ingo Molnar , Andi Kleen , Matthew Wilcox , paulmck@linux.vnet.ibm.com, Chris Mason , Andrew Morton , Linux Kernel Mailing List , linux-fsdevel , linux-btrfs , Thomas Gleixner , Nick Piggin , Peter Morreale , Sven Dietrich In-Reply-To: References: <1231283778.11687.136.camel@twins> <1231329783.11687.287.camel@twins> <1231347442.11687.344.camel@twins> <20090107210923.GV2002@parisc-linux.org> <20090107213924.GP496@one.firstfloor.org> <49652C7C.3000909@novell.com> <20090107223317.GB27629@elte.hu> <4965331E.8090202@novell.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 08 Jan 2009 08:10:30 +0100 Message-Id: <1231398630.11687.382.camel@twins> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1378 Lines: 35 On Wed, 2009-01-07 at 15:32 -0800, Linus Torvalds wrote: > > On Wed, 7 Jan 2009, Steven Rostedt wrote: > > > > What would be interesting is various benchmarks against all three. > > > > 1) no mutex spinning. > > 2) get_task_struct() implementation. > > 3) spin_or_sched implementation. > > One of the issues is that I cannot convince myself that (2) is even > necessarily correct. At least not without having all cases happen inder > the mutex spinlock - which they don't. Even with the original patch, the > uncontended cases set and cleared the owner field outside the lock. Yes, 2 isn't feasible for regular mutexes as we have non-atomic owner tracking. I've since realized the whole rtmutex thing is fundamentally difference on a few levels: a) we have atomic owner tracking (that's the lock itself, it holds the task_pointer as a cookie), and b) we need to do that whole enqueue on the waitlist thing because we need to do the PI propagation and such to figure out if the current task is even allowed to acquire -- that is, only the highest waiting and or lateral steal candidates are allowed to spin acquire. -- 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/