Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750761AbWC3TL1 (ORCPT ); Thu, 30 Mar 2006 14:11:27 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750757AbWC3TL1 (ORCPT ); Thu, 30 Mar 2006 14:11:27 -0500 Received: from omx1-ext.sgi.com ([192.48.179.11]:10907 "EHLO omx1.americas.sgi.com") by vger.kernel.org with ESMTP id S1750756AbWC3TL0 (ORCPT ); Thu, 30 Mar 2006 14:11:26 -0500 Date: Thu, 30 Mar 2006 11:11:15 -0800 (PST) From: Christoph Lameter To: Nick Piggin cc: Zoltan Menyhart , "Boehm, Hans" , "Grundler, Grant G" , "Chen, Kenneth W" , akpm@osdl.org, linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org Subject: Re: Fix unlock_buffer() to work the same way as bit_unlock() In-Reply-To: <442B9D18.4050903@yahoo.com.au> Message-ID: References: <65953E8166311641A685BDF71D865826A23D40@cacexc12.americas.cpqcorp.net> <442B9A2A.7000306@bull.net> <442B9D18.4050903@yahoo.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1372 Lines: 41 On Thu, 30 Mar 2006, Nick Piggin wrote: > Zoltan Menyhart wrote: > > > However, I do not think your implementation would be efficient due to > > selecting the ordering mode at run time: > > > > > + switch (mode) { > > > + case MODE_NONE : > > > + case MODE_ACQUIRE : > > > + return cmpxchg_acq(m, old, new); > > > + case MODE_FENCE : > > > + smp_mb(); > > > + /* Fall through */ > > > + case MODE_RELEASE : > > > + return cmpxchg_rel(m, old, new); > > > > BTW. Isn't MODE_FENCE wrong? Seems like a read or write could be moved > above cmpxchg_rel? Hmmm.... We should call this MODE_BARRIER I guess... > I think you need rel+acq rather than acq+rel (if I'm right, then the > same goes for your earlier bitops patches, btw). The question is what does fence imply for the order of the atomic operation. Will the operation be performed before or after the barrier? Or do we need barriers on both sides? If so then we may simulate that with a release and then do a acquire load afterwards cmpxchg_rel(m, old, new); return *m; /* m volatile so it has acquire semantics */ - 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/