Re: New driver mtipx2xx submission

[Asai Thambi S P <asamymuthupa@micron.com>]

[-- Attachment #1: Type: text/plain, Size: 1748 bytes --]

On 5/11/2011 1:20 PM, Alan Cox wrote:
> So a bigger queue helped (at least in 2006). The AHCI driver can be
> taught your bigger queue easily enough. The question is where with a
> *current* kernel are any remaining bottlenecks if you do that and how do
> we fix them.

Attached image/table shows the performance numbers on current kernel.

The main objectives of our new mtipx2xx driver are
	1.) highest performance (see attached image/table),
	2.) lowest CPU utilization, and
	3.) vendor unique code required to control the P320

We ran our tests (2 iterations) on RHEL 6.0 running kernel 2.6.38.6, 
latest stable kernel then (now I see 2.6.39 as latest stable one). The 
colored cells in the table indicates that AHCI driver was experiencing 
excessive write failures on the P320 which caused the AHCI driver to 
disable NCQ.

Other aspects:
  * This driver works with standard tools like smartctl, hdparm, etc.
  * We are committed to ongoing support in the kernel for this driver
  * This driver is open for other vendors to use
  * Layered driver architecture gives scope for adding interfaces other 
than AHCI i.e. this driver is not limited by AHCI interface

Driver achitecture:
mtipx2xx contain three layers –
  * pci – implementation of all pci related functions
  * block – implementation of all block related functions
  * ahci – implementation of all ahci interface.


> I was expecting at the very least numbers versus a modern kernel (Would
> you do Windows 7 submission benchmarks against XP SP 2 ??) and profile
> data to show where the bottlenecks appear to be.

I knew the numbers on current kernel would make more sense, but then I 
wanted to first post what I had, and then get the latest numbers ready.

Regards,
Asai Thambi

[-- Attachment #2: mtipx2xx_benchmark_comparison.PNG --]
[-- Type: image/png, Size: 63470 bytes --]