Date: Sat, 14 Jan 2006 08:28:11 -0700 From: Scott Long <scottl@samsco.org> To: Steve Kargl <sgk@troutmask.apl.washington.edu> Cc: current@freebsd.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: Extreme contigmalloc() slowness with mpt driver Message-ID: <43C9188B.3050300@samsco.org> In-Reply-To: <20060114055347.GA45580@troutmask.apl.washington.edu> References: <20060114052117.GA16773@xor.obsecurity.org> <20060114055347.GA45580@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Steve Kargl wrote: > On Sat, Jan 14, 2006 at 12:21:17AM -0500, Kris Kennaway wrote: > >>I have an amd64 machine with 16GB of RAM that takes ages to boot (~40 >>minutes on 7.0). This is because the mpt driver takes 20 minutes to >>attach (with 2 instances). This in turn is because the following code >>from dev/mpt/mpt_pci.c:mpt_dma_mem_alloc() takes about 5 seconds to >>execute, and it is run 256 times in a loop: >> >> error = bus_dmamap_create(mpt->buffer_dmat, 0, &req->dmap); >> >>When I set vm.old_contigmalloc=1, the system boots without delay. >> >>This points to a bug in contigmalloc. >> > > > This is probably related to my recent reports of extremely > slow probing of fxp0. I have 12 GB on a Tyan K8S Pro and > fxp0 takes on the order of 7 minutes to probe. > Yep, that's the same reason. THe issue here is that bus_dmamap_create is using contigmalloc to allocate bounce pages for the device. At the request of Soeren, I recently upped the max limit on bounce pages from 512 to 4096. Before that, drivers would quickly reach the max and then move on. Now that the max is a lot higher, I guess it points to a scalability problem in the page search algorithm of contigmalloc. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43C9188B.3050300>