Date: Tue, 10 Mar 2015 14:06:10 -0600 From: Ian Lepore <ian@freebsd.org> To: Scott Long <scott4long@yahoo.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r279828 - head/sys/dev/cadence Message-ID: <1426017970.33324.28.camel@freebsd.org> In-Reply-To: <9F60FF00-B6B4-4197-993A-9848F1C3A923@yahoo.com> References: <201503092239.t29MdxUo089384@svn.freebsd.org> <9F60FF00-B6B4-4197-993A-9848F1C3A923@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2015-03-10 at 13:33 -0600, Scott Long wrote: > > On Mar 9, 2015, at 4:39 PM, Ian Lepore <ian@FreeBSD.org> wrote: > >=20 > > Author: ian > > Date: Mon Mar 9 22:39:58 2015 > > New Revision: 279828 > > URL: https://svnweb.freebsd.org/changeset/base/279828 > >=20 > > Log: > > Use the new ifnet API. Also, allocate bus_dma_maps as needed instea= d of > > pre-allocating them all at start-up. Also fix a bug in cgem_stop();= before, > > it wasn't properly unloading dma maps due to a cut-and-paste error. > >=20 >=20 > It=A2s generally a very bad idea to create and destroy maps for every t= ransaction. If the map > results in being non-NULL, then you=A2re allocating and freeing memory = on every transaction, > and possibly allocating and freeing large chunks of memory for bounce b= uffers. Is there > a reason why you=A2ve made this change? Maps are always non-NULL on arm. Bounce pages are managed in pools and the initial minimum allocation happens when the first mapping is created, then extended as needed to keep a minimum of two bounce pages per map using that pool. Since mbufs never actually bounce on arm the pool just sits there at minimum allocation size, wasting a bit of memory but not costing any cycles on subsequent mappings, unless there are many maps created at once, in which case each new mapping created adds a couple more pages to the pool (which will still never get used). So creating 1024 maps all at once results in a bounce pool with 2048 pages in it, none of which will ever be used in the case of mbufs (because mbufs get to violate the rules about the buffer being aligned to a cacheline boundary, which is the primary cause of bouncing on arm). -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1426017970.33324.28.camel>