Re: Recent concurrency improvements in the AHCI driver and CAM need testing

[Naoya Sugioka <naoya.sugioka@xxxxxxxxx>]

> set debug.acpi.disabled="pci pci_link pcib"

I tried this, with several variations, but it does not help. Seems
you've done some changes I saw,
I'll update source to the latest again, then post the result

thank you,
-Naoya

On Mon, Apr 11, 2011 at 12:02 AM, Sepherosa Ziehau <sepherosa@gmail.com> wrote:
> On Mon, Apr 11, 2011 at 2:39 PM, Naoya Sugioka <naoya.sugioka@gmail.com> wrote:
>> correction :)
>>  io_acpi  => io_apic
>
> On the latest master in loader prompt:
> set debug.acpi.disabled="pci pci_link pcib"
>
> See whether the timeout still happens.
>
>
> But I do observed some ahci CMD timeout in VirtualBox 3.2.12 after
> recent ahci changes:
>
> ahci0.0: CMD TIMEOUT state=5 slot=18
>        cmd-reg 0xdf17<CR,FR,FRE,POD,SUD,ST>
>        sactive=00040000 active=00000000 expired=00000000
>           sact=00000000     ci=00000000
>            STS=50
> ahci0.0: disk_rw: timeout
> (da0:ahci0:0:0:0): Command timed out
> (da0:ahci0:0:0:0): Retrying Command
> ahci0.0: CMD TIMEOUT state=5 slot=18
>        cmd-reg 0xdf17<CR,FR,FRE,POD,SUD,ST>
>        sactive=00040000 active=00000000 expired=00000000
>           sact=00000000     ci=00000000
>            STS=50
> ahci0.0: disk_rw: timeout
> (da0:ahci0:0:0:0): Command timed out
> (da0:ahci0:0:0:0): Retrying Command
>
> Though it does not seem to affect anything else.
>
> Best Regards,
> sephe
>
>>
>> On Sun, Apr 10, 2011 at 11:37 PM, Naoya Sugioka <naoya.sugioka@gmail.com> wrote:
>>> Hello,
>>>
>>> This is happened before your recent update, but my laptop showing
>>> CMD=15; timeout
>>> on ahci0.1 when io_acpi is enabled.  This timeout prevents to complete
>>> bootstrap process.
>>> I just wonder this is happened because ahci.0.1 is associated to ATAPI
>>> (DVD-RW) drive without
>>> occupant.
>>>
>>> dmesg telles:
>>> ahci0.1: Found ATAPI "TSSTcorp DVD+/-RW TS-U633F D200" serial="R3476GSSA81272"
>>> ahci0.1: tags=0/32 satacap=0202 satafea=0068 NCQ=NO capacity=1.00MB
>>> ahci0.1: f85=0000 f86=0000 f87=4000 WC=notsupp RA=notsupp SEC=notsupp
>>>
>>> then start showing a timeout message.
>>>
>>> Let me know if you need further information, thank you.
>>> -Naoya
>>>
>>> On Sat, Apr 9, 2011 at 9:00 PM, Matthew Dillon
>>> <dillon@apollo.backplane.com> wrote:
>>>>    I've pushed some serious changes to the AHCI SATA driver and CAM.
>>>>
>>>>    One fixes issues where the tags were not being utilized to their fullest
>>>>    extent... well, really they weren't being utilized at all.  I'm not
>>>>    sure how I missed the problem before, but it is fixed now.
>>>>
>>>>    The second ensures that read requests cannot saturate all available
>>>>    tags and cause writes to stall, and vise-versa, and also separates
>>>>    out the read and write BIO streams and treats them as separate entities,
>>>>    which means that reads can continue to be dispatched even if writes
>>>>    saturate the drive's cache and writes can continue to be dispatched
>>>>    even if concurrent read(s) would otherwise eat all available tags.
>>>>
>>>>    The reason the read/write saturation fixes are important is because
>>>>    writes are usually completed instantly since they just go to the drive
>>>>    cache, so even if reads are saturated there's no reason not to push
>>>>    writes to the drive.  Plus when the HD's cache becomes saturated writes
>>>>    no longer complete instantly and would prevent reads from being
>>>>    dispatched if all the tags were used to hold the writes.
>>>>
>>>>    --
>>>>
>>>>    With these fixes I am getting much better numbers with concurrency
>>>>    tests:
>>>>
>>>>    I now get around 37000 IOPS doing random 512-byte sector reads with
>>>>    a Crucial C300 SSD, verses ~8000 or so before the fix.
>>>>
>>>>    And I now get around ~365 IOPS with the same test on a hard drive,
>>>>    verses ~150 IOPS before (remember these are random reads!).
>>>>
>>>>    blogbench also appears to have much better write/read parallelism
>>>>    against the swapcache with the SSD/HD combo.  Memory caches blow
>>>>    out at around blog #1300 on my test boxes.
>>>>
>>>>        With the changes blogbench write performance is maintained through
>>>>        blog #1600 or so, without the changes it drops off at #1300.
>>>>
>>>>        With the changes the swapcache SSD is pushing ~1400 IOPS or so
>>>>        satisfying random read requests.  Without the changes the swapcache
>>>>        SSD is only pushing ~130 IOPS.
>>>>
>>>>        With the changes blogbench is able to maintain a ~60000 article
>>>>        read rate at the end of the test.  Without the changes the
>>>>        read rate is more around ~10000 at the end of the test.  At this
>>>>        stage swapcache has cached a significant chunk of the data
>>>>        in the SSD so the I/O activity is mixed random SSD and HD reads.
>>>>
>>>>    --
>>>>
>>>>    Ok, so I feel a bit sheepish that I missed the fact that the AHCI
>>>>    driver wasn't utilizing its tags properly before.  The difference
>>>>    in performance is phenominal.  Maybe we will start winning some
>>>>    of those I/O benchmark tests now.
>>>>
>>>>                                        -Matt
>>>>                                        Matthew Dillon
>>>>                                        <dillon@backplane.com>
>>>>
>>>
>>
>>
>
>
>
> --
> Tomorrow Will Never Die
>