Re: [patch[ twa, bus_dma.h, busdma_machdep.c (amd64)
On Sat, April 29, 2006 5:03 pm, Scott Long said: 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. Running a 3ware 9550sx-4lp on FreeBSD 6.1-PRERELEASE from 3-25-06 and no problem with long boot time, is this unique to amd64 ? -kim -- w8hdkim er gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch[ twa, bus_dma.h, busdma_machdep.c (amd64)
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[patch[ twa, bus_dma.h, busdma_machdep.c (amd64)
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. Yippie! This leaves me with about a 7 - 10 minute boot time. 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 busdma_machdep.c.patch Description: Binary data bus_dma.h.patch Description: Binary data tw_osl_freebsd.c.patch Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
