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 P320We 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:
mtipx2xx_benchmark_comparison.PNG
Description: PNG image
