Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762210AbZAGWAx (ORCPT ); Wed, 7 Jan 2009 17:00:53 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758130AbZAGV77 (ORCPT ); Wed, 7 Jan 2009 16:59:59 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:43745 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1762174AbZAGV74 (ORCPT ); Wed, 7 Jan 2009 16:59:56 -0500 Date: Wed, 7 Jan 2009 13:58:45 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Peter Zijlstra cc: Steven Rostedt , paulmck@linux.vnet.ibm.com, Gregory Haskins , Ingo Molnar , 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 -v5][RFC]: mutex: implement adaptive spinning In-Reply-To: <1231365115.11687.361.camel@twins> Message-ID: References: <87r63ljzox.fsf@basil.nowhere.org> <20090103191706.GA2002@parisc-linux.org> <1231242031.11687.97.camel@twins> <20090106121052.GA27232@elte.hu> <4963584A.4090805@novell.com> <20090106131643.GA15228@elte.hu> <1231248041.11687.107.camel@twins> <49636799.1010109@novell.com> <20090106214229.GD6741@linux.vnet.ibm.com> <1231278275.11687.111.camel@twins> <1231279660.11687.121.camel@twins> <1231281801.11687.125.camel@twins> <1231283778.11687.136.camel@twins> <1231329783.11687.287.camel@twins> <1231347442.11687.344.camel@twins> <1231365115.11687.361.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: 1118 Lines: 35 On Wed, 7 Jan 2009, Peter Zijlstra wrote: > > Do we really have to re-do all that code every loop? No, you're right, we can just look up the cpu once. Which makes Andrew's argument that "probe_kernel_address()" isn't in any hot path even more true. > Also, it would still need to do the funny: > > l_owner = ACCESS_ONCE(lock->owner) > if (l_owner && l_owner != thread) > break; Why? That would fall out of the if (lock->owner != thread) break; part. We don't actually care that it only happens once: this all has _known_ races, and the "cpu_relax()" is a barrier. And notice how the _caller_ handles the "owner == NULL" case by not even calling this, and looping over just the state in the lock itself. That was in the earlier emails. So this approach is actually pretty different from the case that depended on the whole spinlock thing. 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/