Re: [PATCH] speed up SATA

[Jens Axboe <axboe@suse.de>]

On Sun, Mar 28 2004, Jeff Garzik wrote:
> Jens Axboe wrote:
> >On Sat, Mar 27 2004, Jeff Garzik wrote:
> >
> >>Nick Piggin wrote:
> >>
> >>>I think 32MB is too much. You incur latency and lose
> >>>scheduling grainularity. I bet returns start diminishing
> >>>pretty quickly after 1MB or so.
> >>
> >>See my reply to Bart.
> >>
> >>Also, it is not the driver's responsibility to do anything but export 
> >>the hardware maximums.
> >
> >
> >The problem is that what the 'reasonable size' is depends highly on the
> >hardware. The 32MB doesn't make any sense to me for SATA (or for
> >anything else, for that matter). Back-to-back 1MB requests (this is the
> >default I chose for PATA) should be practially identical for throughput,
> >and loads better for optimizing latencies. You cannot do much with 32MB
> >requests wrt latency...
> >
> >So you could change ->max_sectors to be 'max allowable io, hardware
> >limitation' and add ->optimal_sectors to be 'best sized io'. I don't see
> >tha it buys you anything, since you'd be going for optimal_sectors all
> >the time anyways.
> >
> >Additionally, a single bio cannot currently be bigger than 256 pages
> >(ie 1MB request on 4k page). This _could_ be increased of course, but
> >not beyond making ->bio_io_vec be bigger than a page. It's already
> >bigger than that on x86 in fact, if you use 64-bit dma_addr_t. For
> >32-bit dma_addr_t 256 entries fit a page perfectly. Merging can get you
> >bigger requests of course.
> >
> >In summary, there needs to be some extremely good numbers and arguments
> >for changing any of this, so far I don't see anything except people
> >drooling over sending 32MB requests.
> 
> I think you're way too stuck on the 32MB number.  Other limitations 
> already limit that further.

Of course I am, this is what you are proposing as the 'optimal io size'
for SATA. I already explain that ->max_sectors is more of a 'best io
size' not 'hardware limit' setting. So if you set that to 32MB, then
that is what you are indicating.

> If and when the upper layers pass down such requests, my driver can
> handle that.  For today, various external limitations and factors --
> such as what you describe above -- mean the driver won't be getting
> anywhere near 32MB requests.  And my driver can handle that just fine
> too.

In that light, I don't think your change makes any sense whatsoever. You
have a different understanding of what max_sectors member does, that's
basically the heart of the discussion.

I don't think it would be too hard to send down a 32MB request if you
just bypass the file system, in fact I would have thought you would have
benched this long before proposing such a modification.

-- 
Jens Axboe