Date: Sun, 08 May 2005 08:35:38 -0600 From: Scott Long <scottl@samsco.org> To: Steven Hartland <killing@multiplay.co.uk> Cc: Willem Jan Withagen <wjw@withagen.nl> Subject: Re: Very low disk performance Highpoint 1820a Message-ID: <427E23BA.7000508@samsco.org> In-Reply-To: <001c01c553da$5554e490$b3db87d4@multiplay.co.uk> References: <069901c54bfd$2967ba40$7f06000a@int.mediasurface.com><427D5AA0.1080609@withagen.nl><002b01c553be$93a5b790$b3db87d4@multiplay.co.uk> <427E0F77.50006@samsco.org> <001c01c553da$5554e490$b3db87d4@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Steven Hartland wrote: > ---- Original Message ----- From: "Scott Long" <scottl@samsco.org> > > >> Steven Hartland wrote: >> >>> If that where the case it would have been it wouldn't have been >>> 46Mb/s it would have been 543Mb/s, just tested it for you :P >> >> >> The RR1280 cards are really just software RAID cards. All of the parity >> calculations are done by the CPU. I couldn't find much evidence that >> the driver has parity routines that are optimized for the CPU, so it's >> likely doing a very inefficient job at it. > > > According to the documentation this is not the case and the XOR > calcs are done in hardware on the onboard HPT 601. Maybe I'm confused and we are talking about different cards. > >> Changing MAXPHYS is very dangerous, unfortunately. The root of the >> problem is that kernel virtual memory (KVA) gets assigned to each I/O >> buffer as it passes through the kernel. If we allow too much I/O through >> at once then we have the very real possibility of exhausting the kernel >> address space and causing a deadlock and/or panic. That is why MAXPHYS >> is set so low. Your DD test is unlikely to trigger a problem, but try >> doing a bunch of DD's is parallel and you likely will. > > > Thanks for the heads up on this scott I'll do some tests to see that > happens. > N.B. I'm currently using 256K instead of 128K which has the same > performance increase as using 1M. > Note: all tests are being done on i386 not AMD64 due to our requirement > for i386 Linux emulation which it is my understanding is not available when > running AMD64 FreeBSD. Linux/i386 emulation works quite well on FreeBSD/amd64 and is getting better every day. There is active development on it at the moment. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?427E23BA.7000508>