Hello, Robert Watson wrote: > 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, I'm trying to understand where GEOM fits in the FreeBSD I/O structure and I only had found the original McKusick figure: http://www.vinumvm.org/vinum/implementation.html could you give a brief description about I/O structure after GEOM? Thank you.Received on Mon Oct 25 2004 - 07:10:20 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:19 UTC