d core processor @3.20GHz) > OS: > RHEL (Enterprise) ver5.5 x64 (2.6.18-194.el5) Linux 2.6.18 was released in July 2006 > Test Software: > Vdbench ver 5.02 > > These experiments were done by changing the queue depth in > vdbench(Q=xxx). > > |------------------------------------| > | ahci | ahci | mtipx2xx| mtipx2xx| > | Q=256 | Q=32 | Q=32 | Q=256 | > |------------------------------------------------------------| > |4k random read (IOPS) | 15,831 |15,763 | 244,795 | 783,778 | > |4k random write (IOPS) | 4,058 | 4,072 | 46,696 | 135,864 | > |128k seq. read (MBps) | 2,284 | 2,258 | 3,295 | 3,060 | > |128k seq. write (MBps) | 1,049 | 1,053 | 2,092 | 2,078 | > |------------------------------------------------------------| 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. 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. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
