ATA rman performance enhancement
Søren Schmidt
sos at DeepCore.dk
Mon Jan 3 11:59:38 PST 2005
Nate Lawson wrote:
> Søren Schmidt wrote:
>
>> Nate Lawson wrote:
>>
>>> While doing some benchmarking of other code, I noticed that there
>>> were a lot of calls to rman_get_bustag/handle(). They weren't taking
>>> up much actual time since they're pretty lightweight but seemed to be
>>> unnecessary.
>>>
>>> I worked up the attached diff and benchmarked it. There are about
>>> 1000 calls a second to the rman routines without this patch and
>>> essentially none with it. It makes about a 1% difference in
>>> throughput under some IO loads. It is only for non-Promise or
>>> non-SII controllers right now since I didn't extend the
>>> initialization step to more than ata-pci.c. The same approach could
>>> be used for the other INW/OUTW calls as well but they're not in the
>>> fast path. I think it may make more of a difference with small reads.
>>
>> 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
>> to not break anything at least.
>
> Yes, I agree. I limited the change only to the IDX macros that were
> 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
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..
>
> It is a minimal difference but with small transfers on a fast drive with
> a low-powered CPU, it's measurable. I made the same change a while back
> 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
doing micro optims, thats what ATA-mkIII is all about in the first
place. However I'll put it back on the TODO list as something to look
into when the time comes...
--
-Søren
More information about the freebsd-current
mailing list