From owner-freebsd-current@FreeBSD.ORG Mon Oct 25 09:10:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EF1916A4CF for ; Mon, 25 Oct 2004 09:10:20 +0000 (GMT) Received: from tierra2.ng.fadesa.es (tierra2.ng.fadesa.es [195.55.55.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41FC543D31 for ; Mon, 25 Oct 2004 09:10:19 +0000 (GMT) (envelope-from fandino@ng.fadesa.es) Received: from [195.55.55.163] ([195.55.55.163]) (authenticated bits=0) by tierra2.ng.fadesa.es (8.12.10/8.12.10) with ESMTP id i9P9AH10016126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 25 Oct 2004 11:10:18 +0200 Message-ID: <417CC2F9.1050900@ng.fadesa.es> Date: Mon, 25 Oct 2004 11:10:17 +0200 From: fandino User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: gl, en, es MIME-Version: 1.0 To: freebsd-current@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: user fandino from 195.55.55.163 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on tierra2 X-Virus-Status: Clean Subject: Re: FreeBSD 5.3b7and poor ata performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: fandino@ng.fadesa.es List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2004 09:10:20 -0000 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.