From owner-freebsd-arch@FreeBSD.ORG Thu Oct 27 20:45:41 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 47B6F106564A; Thu, 27 Oct 2011 20:45:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 058098FC1C; Thu, 27 Oct 2011 20:45:40 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p9RKi9Pl023840 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Thu, 27 Oct 2011 14:44:10 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Thu, 27 Oct 2011 14:43:58 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Adrian Chadd X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Thu, 27 Oct 2011 14:44:11 -0600 (MDT) Cc: 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 20:45:41 -0000 On Oct 27, 2011, at 2:28 PM, Adrian Chadd wrote: > So what I'm proposing is: >=20 > * Make the bus default to use ordered semantics, much like what Linux > does - ie, all IO read/writes (io or memory) are in-order and flushed > with a barrier; > * Add an option which allows the driver to request a region with > loose-running/lazy semantics, what we're supposed to have now, and > then leave barriers up to the driver; > * Print out something nice and loud if a driver decides to use the > lazy/loose semantics, which may result in unpredictable behaviour on > non-{i386,amd64}. >=20 > I'd appreciate some feedback/comments before I go off and code all of = this up. Having an option to support lazy would be easy to code up on x86 where = it isn't needed. However, on some architectures, the bus space routines = are implemented as a series of function calls from a table that's passed = around in the bus_space_t. Those architectures it would be hard to = implement differing behavior like you propose. Having it whine on lazy will ensure that lazy is never used since such a = message will "scare the horses" and people will stamped to using the = synchronous one. One question: What's the slowdown from making everything synchronous? Warner