From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.linux-foundation.org (smtp2.linux-foundation.org [207.189.120.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.linux-foundation.org", Issuer "CA Cert Signing Authority" (verified OK)) by ozlabs.org (Postfix) with ESMTP id 01F39DDE9B for ; Fri, 24 Aug 2007 02:14:52 +1000 (EST) Date: Thu, 23 Aug 2007 09:14:42 -0700 (PDT) From: Linus Torvalds To: Nick Piggin Subject: Re: wmb vs mmiowb In-Reply-To: <20070823035448.GG18788@wotan.suse.de> Message-ID: References: <20070822045714.GD26374@wotan.suse.de> <200708221202.12403.jesse.barnes@intel.com> <20070823022043.GB18788@wotan.suse.de> <20070823035448.GG18788@wotan.suse.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii Cc: linux-ia64@vger.kernel.org, Jesse Barnes , linuxppc-dev@ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, 23 Aug 2007, Nick Piggin wrote: > > OK, but we'd have some kind of functions that are called not to > serialise the CPUs, but to serialise the IO. It would be up to > the calling code to already provide CPU synchronisation. > > serialize_io(); / unserialize_io(); / a nicer name We could call it "mmiowb()", for example? Radical idea, I know. > If we could pass in some kind of relevant resoure (eg. the IO > memory or device or something), then we might even be able to > put debug checks there to ensure two CPUs are never inside the > same critical IO section at once. We could certainly give it the spinlock as an argument. Linus