Date: Fri, 22 Oct 2004 09:55:15 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= <des@des.no> Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 5.3b7and poor ata performance Message-ID: <Pine.NEB.3.96L.1041022095118.48689D-100000@fledge.watson.org> In-Reply-To: <xzp6552yj7d.fsf@dwp.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 22 Oct 2004, Dag-Erling Sm=F8rgrav wrote: > There may be problems with your particular hardware and / or software > configuration, but you're not likely to get those solved by being so > confrontational. >=20 > As regards block sizes: there *is* a definite increase in performance - > almost a full order of magnitude - going from 512 B to 64 kB. For > larger block sizes, you will get a smaller improvement simply from > amortizing the syscall overhead over larger transfers. I have no idea > how Emmanuel Strobl managed to test performance with block sizes of 128 > B and 256 B since the transfer size for an ATA disk needs to be a > multiple of 512 B. FYI, for those interested in looking some more at the storage performance issue. I recently (yesterday) committed some additional KTR trace points related to GEOM processing of bio's in the g_up and g_down threads. Using these KTR points, you can measure how long it took to get from the system call to the delivery to the driver, and then driver back to the reader, as well as the processing that takes place along the way (using the UMA KTR traces I added a month or so ago). Times are in cycles, so have to be converted to something more human-friendly, and KTR adds a non-trivial amount of overhead, so that should be taken into account also. The GEOM tracing identifies the bio address, offset, size, and the name of the target device/layer as it is processed. More information on hooking up to trace with KTR can be found in the KTR man pages, or here: http://www.watson.org/~robert/freebsd/netperf/ktr/ The information there is focussed on network locking and tracing, but if you add KTR_GEOM and remove some of the other flags from KTR_COMPILE, it should reasonably apply. I'm in the throes of instrumenting busdma for KTR in Perforce so that we can trace bounce buffering and other potential sources of performance problems, and assuming I find time this weekend, will also instrument the ATA driver to identify when I/O is sent, acknowledged, etc. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1041022095118.48689D-100000>