From owner-freebsd-arch@FreeBSD.ORG Thu Oct 27 21:19:40 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 5C472106566C; Thu, 27 Oct 2011 21:19:40 +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 18D498FC0A; Thu, 27 Oct 2011 21:19: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 p9RLGdaZ024207 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Thu, 27 Oct 2011 15:16:40 -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 15:16:30 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <02D4199D-851F-4AA4-8E56-F18B7EF0E79A@bsdimp.com> References: <4EA9C197.9080407@feral.com> 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 15:16:41 -0600 (MDT) 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 21:19:40 -0000 On Oct 27, 2011, at 3:05 PM, Adrian Chadd wrote: > On 28 October 2011 04:39, Matthew Jacob wrote: >=20 >> 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. >>=20 >> I also am not sure I agree with your characterization of linux = semantics. >=20 > Hi, >=20 > The point is, all (most?) of the bus glue does flushes if needed. Ie, > if I understand what's going on: >=20 > * amd64/intel, it's not needed; > * mips doesn't implement it yet; Sounds like a mips bug to me. > * ppc (and sparc?) implement a bus flush on each operation anyway. If ppc implements the flush like you say, how is it you found a bug in = ppc from missing flushes? Warner