From owner-freebsd-current@FreeBSD.ORG Mon Jan 3 19:59:38 2005 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 2C51116A4FE for ; Mon, 3 Jan 2005 19:59:38 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 520B343D39 for ; Mon, 3 Jan 2005 19:59:37 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id j03JxXDR049634; Mon, 3 Jan 2005 20:59:35 +0100 (CET) (envelope-from sos@DeepCore.dk) Message-ID: <41D9A3FA.20204@DeepCore.dk> Date: Mon, 03 Jan 2005 20:58:50 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <41D984A5.7010408@root.org> <41D99FBD.8070500@DeepCore.dk> <41D9A2CF.30704@root.org> In-Reply-To: <41D9A2CF.30704@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.4 cc: FreeBSD Current Subject: Re: ATA rman performance enhancement X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2005 19:59:38 -0000 Nate Lawson wrote: > S=F8ren Schmidt wrote: >=20 >> Nate Lawson wrote: >> >>> While doing some benchmarking of other code, I noticed that there=20 >>> were a lot of calls to rman_get_bustag/handle(). They weren't taking= =20 >>> up much actual time since they're pretty lightweight but seemed to be= =20 >>> unnecessary. >>> >>> I worked up the attached diff and benchmarked it. There are about=20 >>> 1000 calls a second to the rman routines without this patch and=20 >>> essentially none with it. It makes about a 1% difference in=20 >>> throughput under some IO loads. It is only for non-Promise or=20 >>> non-SII controllers right now since I didn't extend the=20 >>> initialization step to more than ata-pci.c. The same approach could=20 >>> be used for the other INW/OUTW calls as well but they're not in the=20 >>> fast path. I think it may make more of a difference with small reads= =2E >> >> I had something semilar to this once back when, but since HW got lots = >> faster I couldn't measure it anymore, but maybe things has changed... >> >> Anyhow it needs to be applied to ata-isa.c ata-card.c ata-cbus.c etc=20 >> to not break anything at least.=20 >=20 > Yes, I agree. I limited the change only to the IDX macros that were=20 > used in the fast path although it could apply to all of them. I *must* be applied to those files, otherwise the handle & tag fields=20 are not initialized when using !pci based devices with you patch. >> I'll think about it and eventually do something about it in ATA-mkIII = >> if it really is mesureable again.. >=20 > It is a minimal difference but with small transfers on a fast drive wit= h=20 > a low-powered CPU, it's measurable. I made the same change a while bac= k=20 > in acpi_timer.c since the resource is only allocated once but accessed = > very often and in a low-latency context. Right, but I'd like to get the much bigger fishes catched first before=20 doing micro optims, thats what ATA-mkIII is all about in the first=20 place. However I'll put it back on the TODO list as something to look=20 into when the time comes... --=20 -S=F8ren