From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert Hancock Subject: Re: Compact Flash performance... Date: Thu, 31 May 2007 18:00:12 -0600 Message-ID: <465F618C.1020200@shaw.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from shawidc-mo1.cg.shawcable.net ([24.71.223.10]:52528 "EHLO pd2mo2so.prod.shaw.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753115AbXFAAAM (ORCPT ); Thu, 31 May 2007 20:00:12 -0400 In-reply-to: Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Jeff Garzik Cc: Mark Lord , Daniel J Blueman , bzolnier@gmail.com, linux-ide@vger.kernel.org, Linux Kernel , Alan Cox Jeff Garzik wrote: > Mark Lord wrote: >> To maximize throughput, some kind of host-queuing would be needed, >> or just have the driver sit in a tight loop, starting the next I/O >> immediately when the previous one finishes. Linux isn't that quick >> (yet). > > > I was talking on IRC with Tejun just recently. There are several > controllers (and/or "situations") like this, where some amount of host > queueing would permit greater throughput, even when NCQ is not > supported. sata_sx4 is the most dramatic example, where host queueing > could potentially increase speed by a factor of 10 or more, since it is > penalized by an awful two-irq-per-command (w/ a per-host bottleneck to > boot) setup. Silicon Image has a "command buffer". And overall, I > designed ->qc_prep() hook separate from ->qc_issue() to enable the > prepartion of multiple commands such that it only takes a simple "go" > I/O to start a transaction, immediately after the previous one ends. > > Jeff Theoretically NVIDIA nForce4 ADMA could likely do this as well, as it seems to allow chaining up multiple commands to execute in succession (assuming they're not NCQ).. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/