On 11-05-02 02:40 PM, Jeff Moyer wrote: .. > Given the highly parallel nature of these parts, I wouldn't be surprised > if the ahci queue depth of 31 is one of the main bottlenecks. Can you > think of a way to extend the ahci driver in this manner to accommodate > devices like this one? .. I imagine that another performance drain might be libata's lack of support for host controller queues --> a hardware queuing layer that exists between the host and the drive's own queuing mechanism. Most modern ATA/SATA chipsets have something of that nature. These are designed to eliminate the activity-gaps that happen between when a drive finishes a command, and when the host interrupt -> BH -> whatever gets around to submitting a new command. With commands already batched up in a hardware host queue, the controller takes care of that part, keeping the drive active more of the time, increasing IOPS. Cheers -- 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
