Re: FIXED: mpt Serious performance issues

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Fri, Feb 04, 2011 at 02:19:09PM +0100, Stephan wrote:
> Have a look at these values:
> 
> ====================
> 
> find / -exec cat {} \; > /dev/null
> 
> Disks:   fd0   cd0   sd0   md0
>  seeks
>  xfers              1085
>  bytes               68M
>  %busy              92.4
> 
> ====================
> 
> bsddev# dd if=/dev/zero of=myfile bs=4096 count=100000
> 100000+0 records in
> 100000+0 records out
> 409600000 bytes transferred in 6.516 secs (62860650 bytes/sec)
> bsddev# ls -lh myfile
> -rw-r--r--  1 root  wheel  391M Feb  4 15:28 myfile
> 
> ===================
> 
> This is approx. the maximum performance of the old hardware.
> 
> So what is wrong with the driver? There are 16 pages represented by
> fCONFIG_PAGE_SCSI_DEVICE_1 available in the controller and every
> single page represents one *PHYSICAL* SCSI target. For example, in
> mpt_set_xfer_mode(), such a page is assembled with the requested modes
> and then trasferred to the controller via mpt_write_cfg_page(). When
> the computer starts, the LSI Firmware BIOS scans the disks and sets a
> meaningful initial setup for each of them. The debugging code shows
> that on NetBSD boot (2 disks were inserted):
> 
> Feb  4 14:19:30 bsddev /netbsd: mpt0: SPI Tgt 0 Page 0: NParms
> 201f08c7 Information 1
> Feb  4 14:19:30 bsddev /netbsd: mpt0: SPI Tgt 0 Page 1: RParms
> 201f0807 Configuration 0
> Feb  4 14:19:30 bsddev /netbsd: mpt0: SPI Tgt 1 Page 0: NParms
> 201f08c7 Information 1
> Feb  4 14:19:30 bsddev /netbsd: mpt0: SPI Tgt 1 Page 1: RParms
> 201f0807 Configuration 0
> Feb  4 14:19:30 bsddev /netbsd: mpt0: SPI Tgt 2 Page 0: NParms 0 Information 0
> Feb  4 14:19:30 bsddev /netbsd: mpt0: SPI Tgt 2 Page 1: RParms 0 
> Configuration 6
> ...
> 
> What then happens is very stupid. The driver calls
> mpt_set_initial_config() in mpt.c which resets every 16 target device
> pages to 0:
> 
> Feb  4 14:19:30 bsddev /netbsd: mpt0: Set Tgt 0 SPI DevicePage 1 values to 0 
> 0 0
> Feb  4 14:19:30 bsddev /netbsd: mpt0: SPI Tgt 0 Page 1: RParm 0 Configuration > 0
> Feb  4 14:19:30 bsddev /netbsd: mpt0: Set Tgt 1 SPI DevicePage 1 values to 0 
> 0 0
> Feb  4 14:19:30 bsddev /netbsd: mpt0: SPI Tgt 1 Page 1: RParm 0 Configuration > 0
> Feb  4 14:19:30 bsddev /netbsd: mpt0: Set Tgt 2 SPI DevicePage 1 values to 0 
> 0 0
> Feb  4 14:19:30 bsddev /netbsd: mpt0: SPI Tgt 2 Page 1: RParm 0 Configuration > 0
> ...
> 
> Now every physical disk, being part of a RAID array or not, runs in a
> prehistoric mode. When the scsipi layer then scans the bus and detects
> the virtual target (sd0), the target device page for disk 0 again gets
> initialized with useful values (this is the fast, lower disk) but the
> page for disk 1 obviously not (this is the slow, upper disk). A simple
> but useful solution seems to be the removal of the code which clears
> all of the target pages as they were initialized correctly by the
> Firmware BIOS. A patch is attached. Comments? Is this good for
> commitment?

At the very last this change should apply only when the controller is in
RAID mode. In this case, the driver should also probably ignore the
modes set from the upper layer.

What should probably be done is that the driver should initialize each
disk by itself, if it has an opportunity to do so (can it still do
an INQUIRY to each target ?), in case the BIOS didn't have the opportunity
to run.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--