From owner-freebsd-arm@FreeBSD.ORG Tue Aug 7 21:45:08 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6673106564A for ; Tue, 7 Aug 2012 21:45:08 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id 848558FC0C for ; Tue, 7 Aug 2012 21:45:03 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta10.emeryville.ca.mail.comcast.net with comcast id jxE81j0011eYJf8AAxkxbY; Tue, 07 Aug 2012 21:44:57 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta19.emeryville.ca.mail.comcast.net with comcast id jxkv1j00F4NgCEG01xkwPi; Tue, 07 Aug 2012 21:44:56 +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 q77LirUP008514; Tue, 7 Aug 2012 15:44:53 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Peter Jeremy In-Reply-To: <20120807212537.GB10572@server.rulingia.com> References: <20120703111753.GB72292@server.rulingia.com> <20120708110516.GA38312@server.rulingia.com> <201207120826.05577.jhb@freebsd.org> <201208061026.06328.jhb@freebsd.org> <1344355782.1128.186.camel@revolution.hippie.lan> <20120807212537.GB10572@server.rulingia.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 07 Aug 2012 15:44:53 -0600 Message-ID: <1344375893.1128.230.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org, mips@freebsd.org Subject: Re: On-stack allocation of DMA S/G lists X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 21:45:08 -0000 On Wed, 2012-08-08 at 07:25 +1000, Peter Jeremy wrote: > On 2012-Aug-07 10:09:42 -0600, Ian Lepore wrote: > >And just for the record, looking at the problem from an even more > >distant vantage... is there really a problem with stack-allocating the > >segments? On a 64-bit arch the struct is like 16 bytes. Typical usage > >is to allocate a tag allowing 1 or just a few segments. Is anyone > >really going to create a tag specifying hundreds of segments that would > >overflow the stack? > > The example that led me to study the code was drm(4). Video cards > typically require fairly large allocations (32MB in my case) but don't > require the RAM to be contiguous - ie it created a tag with 8192 > segments in my case. This may not be relevant to most arm or mips > hosts but drm(4) is MI code that can (theoretically) be built on these > architectures and is a real example where a tag can have many > segments. > > > If they try, wouldn't failing the tag create be good enough? > > No. The caller specifies the hardware limits for the device. They > should not need to take into account implementation details that > mean the full hardware capabilities are not needed. We don't fail > a tag create if it specifies that RAM above 4GB can be used when > we don't have any. Why should be fail a tag create that allows the > use of up to 8192 tags when we only support 1? > Oh, good example. I was wondering if there was any realistic need for lots of segments, and a big video buffer is exactly that. -- Ian