Recent concurrency improvements in the AHCI driver and CAM need testing
Sepherosa Ziehau
sepherosa at gmail.com
Mon Apr 11 00:10:53 PDT 2011
On Mon, Apr 11, 2011 at 2:39 PM, Naoya Sugioka <naoya.sugioka at 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 at 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 at 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 at backplane.com>
>>>
>>
>
>
--
Tomorrow Will Never Die
More information about the Users
mailing list