On 01/13/2011 07:06 PM, ççé wrote:
Hi,
Yes, what I see is every time scsi_request_fn is called, we can only pop
up one request to be dispatched. So, How can we make block layer to
pass more than one commands to us? So that we can fill up more
commands into the Command List before write Px.CI. I think it might
shorten the command interval time.
Even I enable the NCQ, I observed that there is only one command to be
executed per time and tag 0 is used.
That sounds like the I/O pattern doesn't result in any concurrent
transfers being executed. What kind of workload is this running?
Is there any possible to change the libata and ahci.c to be able to fire up
more than one commands at one time and report complete multiple to
upper layer(SCSI and block layer).
Another question, at scsi_adjust_queue_depth() function, why sdev->ordered_tags
and sdev->simple_tags value is only 0 or 1 regardless of queue_depth? What
does it mean?
Thank you in advance for your explanation.
On Fri, Jan 14, 2011 at 1:46 AM, Jeff Garzik<jeff@xxxxxxxxxx> wrote:
On 01/13/2011 05:52 AM, ççé wrote:
Hello,
Inside ahci_qc_issue() function, I see that driver always write one bit
to Px.CI register even enable the NCQ.
AHCI allows to fire 32 commands at one time and AHCI driver also
claims itself able to queue up to 31 commands.
Inside ahci.c :
static struct scsi_host_template ahci_sht = {
ATA_NCQ_SHT(DRV_NAME),
.can_queue = AHCI_MAX_CMDS - 1,
............
Why upper layer(Block or SCSI layer) does not fill up as many as possible
commands into Command List before sending the commands out
(Write to Px.CI register)?
The driver successfully executes up to 31 commands at a time, in paralle.
We submit one command at a time to hardware because the block layer passes
commands to us one at a time.
Jeff
--
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
--
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
