Re: [PATCH] speed up SATA

Bartlomiej Zolnierkiewicz wrote:
> On Sunday 28 of March 2004 00:04, Stefan Smietanowski wrote:
>
>>Hi Jeff.
>>
>>
>>>The "lba48" feature in ATA allows for addressing of sectors > 137GB, and
>>>also allows for transfers of up to 64K sector, instead of the
>>>traditional 256 sectors in older ATA.
>>>
>>>libata simply limited all transfers to a 200 sectors (just under the 256
>>>sector limit).  This was mainly being careful, and making sure I had a
>>>solution that worked everywhere.  I also wanted to see how the iommu S/G
>>>stuff would shake out.
>>>
>>>Things seem to be looking pretty good, so it's now time to turn on
>>>lba48-sized transfers.  Most SATA disks will be lba48 anyway, even the
>>>ones smaller than 137GB, for this and other reasons.
>>>
>>>With this simple patch, the max request size goes from 128K to 32MB...
>>>so you can imagine this will definitely help performance.  Throughput
>>>goes up.  Interrupts go down.  Fun for the whole family.
> What about latency?
> What about recently discussed PRD table "limit" of 256 entries?
> AFAIR these are the reasons why IDE driver is currently
> limiting max request size to 1024K on LBA48 disks.

That's the main limitation on request size right now...  libata limits S/G
table entries to 128[1], so a perfectly aligned, fully merged transfer will
top out at 8MB.  You don't see that unless you're on a totally quiet
machine with tons of free, contiguous pages.  So in practice it winds up
being much smaller, the more loaded the system gets (and pagecache gets
fragmented).

Latency definitely changes for the default case, but remember that a lot of
that is writeback, or streaming writes.  Latency-sensitive applications
already know how to send small or no-wait I/Os, because standard pagecache
writeback latency is highly variable at best :)

	Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/