Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 29 Apr 2006 15:03:42 -0600
From:      Scott Long <scottl@samsco.org>
To:        Sean Bryant <bryants@gmail.com>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: [patch[ twa, bus_dma.h, busdma_machdep.c (amd64)
Message-ID:  <4453D4AE.9010306@samsco.org>
In-Reply-To: <f6791cc60604291156m39f27a3em615cd5e64a414043@mail.gmail.com>
References:  <f6791cc60604291156m39f27a3em615cd5e64a414043@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4453D4AE.9010306>