Re: Promise SX8 performance issues and CARM_MAX_Q

[Jeff Garzik]

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



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/