![]() | |||||||||||||
Messages in this thread |
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 - 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/ | ||||||||||||
| Last update: 2005-03-22 13:02 [from the cache] ©2003-2008 | |||||||||||||