From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by ozlabs.org (Postfix) with ESMTP id F1421DDE2F for ; Fri, 24 Aug 2007 03:00:09 +1000 (EST) From: Jesse Barnes To: Benjamin Herrenschmidt Subject: Re: wmb vs mmiowb Date: Thu, 23 Aug 2007 09:56:16 -0700 References: <20070822045714.GD26374@wotan.suse.de> <1187854035.5972.4.camel@localhost.localdomain> In-Reply-To: <1187854035.5972.4.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Message-Id: <200708230956.17049.jesse.barnes@intel.com> Cc: Nick Piggin , linux-ia64@vger.kernel.org, Linus Torvalds , linuxppc-dev@ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thursday, August 23, 2007 12:27 am Benjamin Herrenschmidt wrote: > > Of course, the normal memory barrier would usually be a > > "spin_unlock()" or something like that, not a "wmb()". In fact, I > > don't think the powerpc implementation (as an example of this) will > > actually synchronize with anything *but* a spin_unlock(). > > We are even more sneaky in the sense that we set a per-cpu flag on > any MMIO write and do the sync automatically in spin_unlock() :-) Yeah, that's a reasonable thing to do, and in fact I think there's code to do something similar when a task is switched out (this keeps user level drivers from having do mmiowb() type things). FWIW, I think I had an earlier version of the patch that used the name pioflush() or something similar, the only confusing thing about that name is that the primitive doesn't actually force I/Os down to the device level, just to the closest bridge. It'll be interesting to see if upcoming x86 designs share this problem (e.g. large HT or CSI topologies). Jesse