From owner-freebsd-stable@FreeBSD.ORG Sat Apr 29 21:03:38 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1905D16A401 for ; Sat, 29 Apr 2006 21:03:38 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F73343D45 for ; Sat, 29 Apr 2006 21:03:37 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k3TL3ahX018442; Sat, 29 Apr 2006 15:03:36 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4453D4AE.9010306@samsco.org> Date: Sat, 29 Apr 2006 15:03:42 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean Bryant References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-stable@freebsd.org Subject: Re: [patch[ twa, bus_dma.h, busdma_machdep.c (amd64) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Apr 2006 21:03:38 -0000 Sean Bryant wrote: > I loaded up 6.1-Stable on a Dual Dual Core Opteron, with a 3ware > 9550sx-4lp raid card in it and noticed a horrid boot time. > Well after investigating the issue it turns out the twa driver had > problems creating the bus_dmamaps. It was creating 255 request buffers > and giving each of them a dma map. This is exactly what is supposed to happen. > Yippie! This leaves me with about a 7 - 10 minute boot time. This is because contigmalloc is broken and does a N^2 search of pages, starting with pages that are usually the least suitable for what it wants. Yippie indeed. I committed a partial fix for this recently, make sure that you have rev 1.43.2.4 of sys/vm/vm_contig.c. > > To correct this problem I created a bus_dmamap_create_v (should probably > be called bus_dmamap_create_many as mux suggested) and this creates a > large amount of dma maps all at once. > Obviously to test I modified the twa driver to use the new function. > I've seen no problems so far. let me know if you see any glaring errors. > As there are probably some. Disk performance remained the same just > speed up boot time considerably. This is only tested with amd64 code. > The code *should* work with i386, but I wasn't able to test it. Please > test and let me know of any problems. > > And I apologize ahead of time if this is useless I don't know much about > the topic but was in need of a quick fix. > -- > Sean Bryant > Your method assumes that there will always be a bus_dmamap_t object allocated. It's not explicitely wrong, but not very optimal either. If the above fix to vm_contig.c doesn't help you, let me know and we can work out a more complete fix. Another thing to tweak is to add the following to /boot/loader.conf: vm.old_contigmalloc=1 Scott