From owner-svn-src-all@FreeBSD.ORG Tue Mar 10 20:22:36 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0817F95F; Tue, 10 Mar 2015 20:22:36 +0000 (UTC) Received: from relay.mailchannels.net (tkt-001-i374.relay.mailchannels.net [174.136.5.177]) by mx1.freebsd.org (Postfix) with ESMTP id B94C6A2C; Tue, 10 Mar 2015 20:22:34 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp7.ore.mailhop.org (ip-10-220-9-73.us-west-2.compute.internal [10.220.9.73]) by relay.mailchannels.net (Postfix) with ESMTPA id 127C642B9; Tue, 10 Mar 2015 20:06:20 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp7.ore.mailhop.org (smtp7.ore.mailhop.org [10.45.8.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Tue, 10 Mar 2015 20:06:21 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|hippie X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1426017981194:1682275550 X-MC-Ingress-Time: 1426017981194 Received: from c-73-34-117-227.hsd1.co.comcast.net ([73.34.117.227] helo=ilsoft.org) by smtp7.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YVQPy-00079k-RH; Tue, 10 Mar 2015 20:06:18 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t2AK6Ah8010137; Tue, 10 Mar 2015 14:06:10 -0600 (MDT) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX19Y9I+/zhtxBwsvplVl1sR3 Message-ID: <1426017970.33324.28.camel@freebsd.org> Subject: Re: svn commit: r279828 - head/sys/dev/cadence From: Ian Lepore To: Scott Long Date: Tue, 10 Mar 2015 14:06:10 -0600 In-Reply-To: <9F60FF00-B6B4-4197-993A-9848F1C3A923@yahoo.com> References: <201503092239.t29MdxUo089384@svn.freebsd.org> <9F60FF00-B6B4-4197-993A-9848F1C3A923@yahoo.com> Content-Type: text/plain; charset="iso-8859-7" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 X-AuthUser: hippie Content-Transfer-Encoding: quoted-printable Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 20:22:36 -0000 On Tue, 2015-03-10 at 13:33 -0600, Scott Long wrote: > > On Mar 9, 2015, at 4:39 PM, Ian Lepore 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