HEADS UP: Major CAM performance regression

[Scott Long]

Ivan Voras wrote:
> 2009/2/13 Scott Long <scottl at samsco.org>:
>> Ivan Voras wrote:
>>> Scott Long wrote:
>>>
>>>> I have committed a fix for this problem for FreeBSD 8-CURRENT as of SVN
>>>> revision 188570. FreeBSD 7-STABLE will be updated with the fix in a few
>>>> days once I've gotten confirmation that the fix works and doesn't cause
>>>> any adverse side-effects.  Anyone wanting to help in this validation
>>>> effort should apply the attached patch to their kernel source tree and
>>>> recompile.  Please contact me directly by email to report if the problem
>>>> is fixed for you.
>>> I notice that write performance on an ESXi 3.5 hosted system is doubled,
>>> but read performance remains the same (in bonnie++).
>>> On a CISS system there is no significant change.
>> bonnie is an unreliable tool for measuring performance.
> 
> I'll try your suggestion if you have one.

I don't have a magic universal testing suite in my back pocket, sorry.
You need to look at your expected workload and develop tests to simulate
it.  When I do testing during driver development, I try a lot of
different parallel, sequential, large i/o, and small i/o combinations.

> 
> (except if it's about bonnie++ primarily measuring sequential
> read/write - if a system can't do sequential IO well, it probably
> won't do random IO well)

This is completely false.  Disks can't do sequential i/o very well due
to the physical limits of long seek times, but those seek times can be
greatly amortized, even in a random workload, with tagged queueing and
parallel dispatch from the OS.  Bonnie simply cannot exercise this very
well.

Bonnie tests system latency for discrete I/O's.  That is all it tests.

Scott