Re: Promise SX8 performance issues and CARM_MAX_Q

[Jeff Garzik <jgarzik@pobox.com>]

Matthew Collins wrote:
> Jeff Garzik wrote:
> 
>> Bernard Blackham wrote:
>>
>>> Hi,
>>>
>>> Playing with a recently acquired Promise SX8 card, we've found
>>> similar performance results to Matt's post to lkml a few months back
>>> at http://marc.theaimsgroup.com/?l=linux-kernel&m=110175890323356&w=2
>>>
>>> It appears that the driver is only submitting one command at a time
>>> per port, which is at least one cause of the slowdowns. By raising
>>> CARM_MAX_Q from 1 to 3 in drivers/block/sx8.c (it was 3 in an
>>> earlier pre-merge incarnation of carmel.c), we're getting very
>>> notable speed improvements, with no side effects just yet.
>>>
>>> Knowing very little about what this change has actually done, I've a
>>> few questions:
>>>  - Should this be considered dangerous?
>>>  - Why was it taken from 3 to 1?
>>>  - Is CARM_MAX_Q a number defined (or limited) by the hardware?
>>
>>
>>
>> In multi-port stress tests, we couldn't get SX8 to function reliably 
>> without locking up or corrupting data, with more than one outstanding 
>> command.
>>
>> Maybe a new firmware has solved this by now.
>>
>>     Jeff
>>
>>
>>
> Indeed there does seem to be new firmware out as of 2/23/05. I ran my 
> tests with the 9/10/04 firmware but I did not adjust the CARM_MAX_Q 
> value. Do either of you happen to know what firmware revisions you 
> tested under?
> 
> I've put the machine with the SX8 controller into production despite the 
> performance issues so I'm not going to be of any use for testing 
> revisions to the driver :(

The driver was developed on a pre-production board, so its entirely 
possible Promise fixed this issue.

The driver should be solid for _at least_ CARM_MAX_Q==31, presuming that 
the firmware doesn't choke.

Anybody willing to
(a) change CARM_MAX_Q
(b) use the latest firmware
(c) stress the card with fsx, badblocks, iozone, and other tools
     on -multiple ports- simultaneously.

?

	Jeff