From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Barnes Date: Thu, 23 Aug 2007 16:56:16 +0000 Subject: Re: wmb vs mmiowb Message-Id: <200708230956.17049.jesse.barnes@intel.com> List-Id: 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="us-ascii" Content-Transfer-Encoding: 7bit To: Benjamin Herrenschmidt Cc: Nick Piggin , linux-ia64@vger.kernel.org, Linus Torvalds , linuxppc-dev@ozlabs.org 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 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