Why is only one command issue per time in AHCI driver?

Why is only one command issue per time in AHCI driver?

[羅秉鈞]

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)?

How do I configure my driver so that Block layer can queue more commands
into queue list?


Regards,
BingJiun

Re: Why is only one command issue per time in AHCI driver?

[Jeff Garzik]

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

Re: Why is only one command issue per time in AHCI driver?

[羅秉鈞]

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.

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@garzik.org> 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
>
>
>
>

Re: Why is only one command issue per time in AHCI driver?

[Robert Hancock]

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@garzik.org>  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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Why is only one command issue per time in AHCI driver?

[BingJiun Luo]

I am just thinking how to make commands interval time shorter to have better
performance.

Meanwhile, there is an NCQ feature in SATA specification and block layer also
support tagging, but why we can not utilize this functionality because always
only one command is sent out per time and the tag number is zero even enable
NCQ.

Regards,
BingJiun

On Fri, Jan 14, 2011 at 1:47 PM, Robert Hancock <hancockrwd@gmail.com> wrote:
> 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@garzik.org>  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@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
>

Re: Why is only one command issue per time in AHCI driver?

[Seed]

Hi Robert,

On Fri, Jan 14, 2011 at 4:47 PM, Robert Hancock <hancockrwd@gmail.com> wrote:
> That sounds like the I/O pattern doesn't result in any concurrent transfers
> being executed. What kind of workload is this running?
>

Do you have any suggestion about how to can get such a workload?

Thanks.
-- 
Sidney Amani

Re: Why is only one command issue per time in AHCI driver?

[Jeff Garzik]

On 01/18/2011 02:56 AM, Seed wrote:
> Hi Robert,
>
> On Fri, Jan 14, 2011 at 4:47 PM, Robert Hancock<hancockrwd@gmail.com>  wrote:
>> That sounds like the I/O pattern doesn't result in any concurrent transfers
>> being executed. What kind of workload is this running?
>>
>
> Do you have any suggestion about how to can get such a workload?

Use multiple threads.

Re: Why is only one command issue per time in AHCI driver?

[Robert Hancock]

On Tue, Jan 18, 2011 at 1:56 AM, Seed <seedrubbish@gmail.com> wrote:
> Hi Robert,
>
> On Fri, Jan 14, 2011 at 4:47 PM, Robert Hancock <hancockrwd@gmail.com> wrote:
>> That sounds like the I/O pattern doesn't result in any concurrent transfers
>> being executed. What kind of workload is this running?
>>
>
> Do you have any suggestion about how to can get such a workload?

It depends very much on what you're trying to accomplish. Last time I
checked, even booting the system or doing large sequential I/O would
result in fairly high queue depths. However if you're doing small,
single-threaded I/O, you likely won't see much or any queueing.