From owner-freebsd-arch@FreeBSD.ORG Thu Aug 23 23:45:08 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5FBAD106564A for ; Thu, 23 Aug 2012 23:45:08 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 354978FC18 for ; Thu, 23 Aug 2012 23:45:08 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta01.emeryville.ca.mail.comcast.net with comcast id qEbq1j05S1bwxycA1Pl7fN; Thu, 23 Aug 2012 23:45:07 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta18.emeryville.ca.mail.comcast.net with comcast id qPl61j00R4NgCEG8ePl6lZ; Thu, 23 Aug 2012 23:45:07 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q7NNj4Mr025577; Thu, 23 Aug 2012 17:45:04 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Warner Losh In-Reply-To: References: <1345757300.27688.535.camel@revolution.hippie.lan> <3A08EB08-2BBF-4B0F-97F2-A3264754C4B7@bsdimp.com> <1345763393.27688.578.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Aug 2012 17:45:03 -0600 Message-ID: <1345765503.27688.602.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Partial cacheline flush problems on ARM and MIPS 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, 23 Aug 2012 23:45:08 -0000 On Thu, 2012-08-23 at 17:26 -0600, Warner Losh wrote: > > On Aug 23, 2012, at 3:28 PM, Ian Lepore wrote: > > Now we have a new type of constraint, I think of it as "granularity". > > In effect, we have a DMA system that can only do DMA in cacheline sized > > chunks. Even when the IO size -- and thus the number of "bits on the > > wire" -- is less than the cacheline size, at the end of the DMA > > operation (which includes the software-assisted coherency operations) > > the number of bytes in memory that may be modified is the size of a > > cacheline. This is because "the DMA system" is not just the engine that > > moves bytes around, it's the combination of hardware and software that > > work together to maintain cache coherency. > But this isn't new. It is an alignment requirement, which carries > with it an implicit size requirement. If you enforce the alignment, > and force all 'sub buffers' to have this alignment, you don't need the > new thing. So do you think it's safe to assume that any given dma tag that has an alignment constraint also implicitly has a buffer size constraint that the size must be a multiple of the alignment? What if we have a platform with a 32-byte cacheline / DMA granularity, and then we have a builtin device on that SoC which can only do DMA on a 64K alignment (which its tag would reflect), but the hardware can move as little as 1 byte at a time? Children of that bridge device come along and allocate little 16-byte buffers that eat 16 pages each. It doesn't seem all that far-fetched to me. -- Ian