Date: Fri, 28 Oct 2011 00:10:19 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: Adrian Chadd <adrian@freebsd.org> Cc: mj@feral.com, freebsd-arch@freebsd.org Subject: Re: newbus IO ordering semantics - moving forward Message-ID: <20111027221019.GA99899@alchemy.franken.de> In-Reply-To: <CAJ-Vmomuze%2BfX_NRhB11dJbZX54c=Gqj6EpxjjnP17BtZxCaNQ@mail.gmail.com> References: <CAJ-VmonFJG3xLn2JvarOUN6o-e7MC%2BA%2B=W9_vocZqY6L3CmTmQ@mail.gmail.com> <4EA9C197.9080407@feral.com> <CAJ-Vmomuze%2BfX_NRhB11dJbZX54c=Gqj6EpxjjnP17BtZxCaNQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 28, 2011 at 05:05:50AM +0800, Adrian Chadd wrote: > On 28 October 2011 04:39, Matthew Jacob <mj@feral.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111027221019.GA99899>