From owner-freebsd-current@FreeBSD.ORG Fri Jun 26 07:29:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31FEC1065672 for ; Fri, 26 Jun 2009 07:29:43 +0000 (UTC) (envelope-from kosmo@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id D7C838FC0C for ; Fri, 26 Jun 2009 07:29:42 +0000 (UTC) (envelope-from kosmo@semihalf.com) Received: from [10.0.0.5] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 09431C4026; Fri, 26 Jun 2009 09:28:18 +0200 (CEST) From: Piotr =?iso-8859-2?q?Zi=EAcik?= Organization: Semihalf To: Scott Long Date: Fri, 26 Jun 2009 09:29:40 +0200 User-Agent: PLD Linux KMail/1.9.10 References: <200906251329.35200.kosmo@semihalf.com> <4A43C243.9000001@samsco.org> In-Reply-To: <4A43C243.9000001@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200906260929.40709.kosmo@semihalf.com> Cc: freebsd-current@freebsd.org Subject: Re: [PATCH RFC]: Bus_dma eats all available memory X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 07:29:43 -0000 Thursday 25 June 2009 20:30:27 Scott Long napisa=B3(a): > Piotr Zi=EAcik wrote: > > Hi > > > > While working on new driver for FreeBSD I have found a problem in bus_d= ma > > subsystem. Every time when bus_dmamap_create() is called on bus_dma tag > > using bounce zone, at least 1 page in bounce zone is allocated. This > > causes eating of all avaible memory by bounce zone. Problem affects i38= 6, > > amd64 and arm. > > The code block that you point at can only be entered if the maxpages > limit has not been reached. However, the max limit is per zone, not > global, and there's no easy way to make it be global. Are you creating > an excessive number of tags/zones? Driver creates one tag and and one map everytime when new request arrives. Both are freed after processing. Driver can queue maximum 64 requests, so it there will not be more than 64 tags and 64 maps. Debugging shows that th= e=20 limit is never reached and number of tags and maps is around 30 - 40. In my= =20 oppinion this is not excessive number of tags. I observe one bounce zone with huge amount of pages: hw.busdma.total_bpages: 114428 hw.busdma.zone0.total_bpages: 114428 hw.busdma.zone0.free_bpages: 114428 hw.busdma.zone0.reserved_bpages: 0 hw.busdma.zone0.active_bpages: 0 hw.busdma.zone0.total_bounced: 0 hw.busdma.zone0.total_deferred: 0 hw.busdma.zone0.lowaddr: 0xffffffff hw.busdma.zone0.alignment: 4096 I suppose, that problem could be around BUS_DMA_MIN_ALLOC_COMP flag: =2D-- code --- if ((dmat->flags & BUS_DMA_MIN_ALLOC_COMP) =3D=3D 0 || (bz->map_count > 0 && bz->total_bpages < maxpages)) { =2D-- code --- When new tag is created, an initial bounce zone allocation will be performe= d=20 if BUS_DMA_ALLOCNOW flag is passed to bus_dma_tag_create(). If the allocati= on=20 was not done, the BUS_DMA_MIN_ALLOC_COMP flag is not set and we will enter = to=20 the problematic code block.=20 The idea of my fix is to alloc 0 or more pages when when condition in the i= f=20 statement shown above is true. In current code 1 or more pages will be=20 allocated in that case. Behaviour introduced by my patch seems to work in=20 current ia64 code. =2D-=20 Best Regards, Piotr Ziecik