From owner-freebsd-mips@FreeBSD.ORG Tue Aug 7 21:25:57 2012 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B44D1065670; Tue, 7 Aug 2012 21:25:57 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 743168FC14; Tue, 7 Aug 2012 21:25:55 +0000 (UTC) Received: from server.rulingia.com (c220-239-247-45.belrs5.nsw.optusnet.com.au [220.239.247.45]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q77LPndk049001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Aug 2012 07:25:50 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q77LPcTE011034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Aug 2012 07:25:38 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q77LPbJp011033; Wed, 8 Aug 2012 07:25:37 +1000 (EST) (envelope-from peter) Date: Wed, 8 Aug 2012 07:25:37 +1000 From: Peter Jeremy To: Ian Lepore Message-ID: <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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/NkBOFFp2J2Af1nK" Content-Disposition: inline In-Reply-To: <1344355782.1128.186.camel@revolution.hippie.lan> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arm@freebsd.org, mips@freebsd.org Subject: Re: On-stack allocation of DMA S/G lists X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 21:25:57 -0000 --/NkBOFFp2J2Af1nK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Aug-07 10:09:42 -0600, Ian Lepore w= rote: >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? --=20 Peter Jeremy --/NkBOFFp2J2Af1nK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlAhh9EACgkQ/opHv/APuIfXtQCgkPCHfBAMkK0mE0tBmKqiwVva qO8AnA6dmeOhECocgwzP3A21OG/gEI/i =OnWm -----END PGP SIGNATURE----- --/NkBOFFp2J2Af1nK--