Fwd: Re: Performance figure for sx8 driver

Fwd: Re: Performance figure for sx8 driver

[kallol]

Hello Jeff,
           How did you verify that performance improved making the
changes those
you suggested?

hdparm does not show it.

Regards,
Kallol

Quoting kallol@nucleodyne.com:

> Hello Jeff,
>            Changing CARM_MAX_Q to 30 and upgrading the firmware to
> firmware(BIOS-1.00.0.37, Firmware-1.3.19) does not help.
>
> Anything else to try?
>
> Kallol
>
> Quoting Jeff Garzik <jgarzik@pobox.com>:
>
>> kallol@nucleodyne.com wrote:
>>> Does anyone have performace figure for sx8 driver which is for
>>> promise SATAII150
>>> 8 port PCI-X adapter?
>>>
>>> Someone reports that on a platform with sx8 driver, multiple hdparms on
>>> different disks those are connected to the same adapter (there are
>>> 8 ports) can
>>> not get more than 45MB/sec in total, whereas a SCSI based driver
>>> for the same
>>> adapter gets around 150MB/sec.
>>>
>>> Any comment on this?
>>
>> Known.  Early firmwares for SX8 had problems that forced the driver to
>> limit the number of outstanding requests, for all ports, to _one_.
>>
>> Later firmwares have fixed this, but the driver has not been updated to
>> detect newer(fixed) firmwares.
>>
>> You may update drivers/block/sx8.c as such:
>>
>> - CARM_MAX_Q              = 1,               /* one command at a time */
>> + CARM_MAX_Q              = 30,              /* 30 commands at a time */
>>
>> if you have a newer firmware, to obtain much better performance.
>>
>> 	Jeff
>>
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>





----- End forwarded message -----

Re: Fwd: Re: Performance figure for sx8 driver

[Mark Lord]

kallol@nucleodyne.com wrote:
> 
> 
> Hello Jeff,
>            How did you verify that performance improved making the
> changes those
> you suggested?
> 
> hdparm does not show it.

My hdparm tool performs a single I/O at a time,
disregarding any kernel read-ahead that may be added on.

As such, it won't often show the effects of queued commands
as well as some other test might.

Cheers

Re: Fwd: Re: Performance figure for sx8 driver

[Kallol Biswas]

I have been investigating what the cause of performance loss could be.

I have noticed several things:

0) Setting to CARM_MAX_Q to 30 hangs. So we have been testing only with
CARM_MAX_Q == 1. The firmware has not been updated yet.

1) If we keep on increasing number of SATA disks, hdparm does not get
multiplied total read performance (hdparm -t ....).

With a Maxtor 60 GB disk with 8MB cache we get 50Mb/sec. If we put
two disks we get 35 on each. Total  70MB/sec. If we put more
then total does not get above 70MB/sec.

It  looks like that a part of the driver serializes the commands.
We have a 32 processor MIPS based system.

2) It looks like that there is while(1) loop under spinlock in isr
stack. If we start queuing many commands then it may take a while for
this loop to break. Though I am not quite familiar with the driver yet.

If we set CARM_MAX_Q to 30 then the request/response queue length should
also be increased right?

3)  Next I will put PCI-X analyzer and figure  out the root cause of
performance loss. May be need to get hold of the technical manual.

Kallol

On Sun, 2005-06-12 at 09:30, Mark Lord wrote:
> kallol@nucleodyne.com wrote:
> > 
> > 
> > Hello Jeff,
> >            How did you verify that performance improved making the
> > changes those
> > you suggested?
> > 
> > hdparm does not show it.
> 
> My hdparm tool performs a single I/O at a time,
> disregarding any kernel read-ahead that may be added on.
> 
> As such, it won't often show the effects of queued commands
> as well as some other test might.
> 
> Cheers
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: Re: Performance figure for sx8 driver

[Jeff Garzik]

Kallol Biswas wrote:
> I have been investigating what the cause of performance loss could be.
> 
> I have noticed several things:
> 
> 0) Setting to CARM_MAX_Q to 30 hangs. So we have been testing only with
> CARM_MAX_Q == 1. The firmware has not been updated yet.

Note that CARM_MAX_Q controls the --host-- queue.

This means that, with CARM_MAX_Q==1, only one command can be sent to 
--any-- disk, at a time.  disks 1-7 must wait for disk 0 to complete an 
I/O, and so on.  Each command is host-synchronous.

As such, this limits multi-disk performance quite severely, but does not 
hamper single disk performance.

CARM_MAX_Q==1 is set as such (as mentioned earlier in the thread) 
because early firmwares would lock up if that value was increased.

It has been reported that newer firmwares work fine with CARM_MAX_Q==30, 
which completely eliminates the host-synchronous condition.

	Jeff

Enabling MSI on SATAII150

[Kallol Biswas]

Hello Jeff,
          We have been using the sx8 driver on a MIPS based custom
platform.
It seems the line based interrupt mechanism is broken on the system.

SATA1150 controller supports MSI interrupt like other PCI-X devices.

Unfortunately we do not have access to the controller's technical
specification yet.

Would it be possible to send us a reply detailing how to enable
MSI interrupt on the adapter?

BTW, with CARM_MAX_Q == 30 and a workaround to fix lost interrupt we
have got good performance with the driver. Thanks for good work. MSI
will help improve performance more, as there won't be any delay
associated with handling lost interrupt.


Kallol
     

Re: Enabling MSI on SATAII150

[Jeff Garzik]

Kallol Biswas wrote:
> Hello Jeff,
>           We have been using the sx8 driver on a MIPS based custom
> platform.
> It seems the line based interrupt mechanism is broken on the system.
> 
> SATA1150 controller supports MSI interrupt like other PCI-X devices.
> 
> Unfortunately we do not have access to the controller's technical
> specification yet.
> 
> Would it be possible to send us a reply detailing how to enable
> MSI interrupt on the adapter?

Just add pci_enable_msi() and pci_disable_msi() calls to the driver, 
much like drivers/scsi/ahci.c in 2.6.12-git8.

	Jeff

Re: Enabling MSI on SATAII150

[Jeff Garzik]

Kallol Biswas wrote:
> Hello Jeff,
>           We have been using the sx8 driver on a MIPS based custom
> platform.
> It seems the line based interrupt mechanism is broken on the system.
> 
> SATA1150 controller supports MSI interrupt like other PCI-X devices.
> 
> Unfortunately we do not have access to the controller's technical
> specification yet.
> 
> Would it be possible to send us a reply detailing how to enable
> MSI interrupt on the adapter?

Should be just pci_enable_msi() in the appropriate place.  Look at 
recent drivers/scsi/ahci.c for an example.


> BTW, with CARM_MAX_Q == 30 and a workaround to fix lost interrupt we
> have got good performance with the driver. Thanks for good work. MSI
> will help improve performance more, as there won't be any delay
> associated with handling lost interrupt.

Cool.

	Jeff