From owner-freebsd-arch@FreeBSD.ORG Thu Oct 27 22:22:10 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F7D3106566B for ; Thu, 27 Oct 2011 22:22:10 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id CBBBE8FC12 for ; Thu, 27 Oct 2011 22:22:09 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p9RMAJ2G000234; Fri, 28 Oct 2011 00:10:20 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p9RMAJW2000233; Fri, 28 Oct 2011 00:10:19 +0200 (CEST) (envelope-from marius) Date: Fri, 28 Oct 2011 00:10:19 +0200 From: Marius Strobl To: Adrian Chadd Message-ID: <20111027221019.GA99899@alchemy.franken.de> References: <4EA9C197.9080407@feral.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: mj@feral.com, freebsd-arch@freebsd.org Subject: Re: newbus IO ordering semantics - moving forward X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 22:22:10 -0000 On Fri, Oct 28, 2011 at 05:05:50AM +0800, Adrian Chadd wrote: > On 28 October 2011 04:39, Matthew Jacob wrote: > > > No. Please don't change the current semantics which are well understood if > > only fitfully adhered to. This would put us in the position of having some > > drivers possibly work slower because they didn't do the "lazy" request. > > > > I also am not sure I agree with your characterization of linux semantics. > > Hi, > > The point is, all (most?) of the bus glue does flushes if needed. Ie, > if I understand what's going on: > > * amd64/intel, it's not needed; > * mips doesn't implement it yet; > * ppc (and sparc?) implement a bus flush on each operation anyway. > For sparc64 this statement is false; the bus_space(9) implementation there relies on drivers properly using bus_space_barrier(9), mainly because bus barriers are a rather costly operation there and including them with every bus access for the most part probably unnecessarily just wastes performance. Also virtually all drivers enabled in the sparc64 GENERIC properly issue bus barriers AFAICT as we took care of this when porting "MI" drivers over to work on sparc64 (fixing endianess issues, incorrect use of bus_dma(9) etc). Also ath(4) once worked fine on sparc64, at least when it was added to GENERIC, if it no longer does (which it likely doesn't when bus_space_barrier(9) calls are missing) then this is a regression in ath(4). Also if you count in bus_dma(9) on "bus glue" then the statement that it automagically does flushes if needed also is false; bus_dmamap_sync(9) calls are vital even on x86 in order for bounce buffers to work. Marius