On Fri, Jan 16, 2015 at 3:21 PM, Jens Axboe <axboe@xxxxxx> wrote: > On 01/16/2015 04:17 PM, Jens Axboe wrote: >> On 01/16/2015 04:13 PM, Dan Williams wrote: >>> Jens notes, "libata tag allocator sucks. Like seriously sucks, it's >>> almost a worst case implementation." Previously I thought SATA mmio >>> latency dominated performance profiles, but as Tejun notes: >>> >>> "Hmmm... one problem with the existing tag allocator in ata is that >>> it's not very efficient which actually shows up in profile when libata >>> is used with a very zippy SSD. Given that ata needs a different >>> allocation policies anyway maybe the right thing to do is making the >>> existing allocator suck less." >>> >>> So replace it with a naive enhancement that also supports the existing >>> quirks. Hopefully, soon to be replaced by Shaohua's patches [1], but >>> those do not yet support the quirk needed by sil24 (ATA_FLAG_LOWTAG) >>> [2]. >> >> That's trivial to do, it's just always having '0' in the cache and >> that's where the search would start. > > BTW, I'm still puzzled by why sil24 fails with different tags, I can't > shake the feeling that some other bug is the cause of this. > Yes, a silicon bug :-). Until "8a4aeec8d2d6 libata/ahci: accommodate tag ordered controllers" never saw a different tag order besides the lowest available. But even "lowest available" will race with completions sometimes. In any event, it's a puzzle that needs hardware to solve and I'm not in a position to do anything outside of reverting the new behavior. -- 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
