On Wed, Oct 28, 2009 at 1:58 PM, David Dillow <dillo...@ornl.gov> wrote: > On Wed, 2009-10-28 at 13:38 -0600, Chris Worley wrote: >> There is no scheduler running on either target or initiator on the >> drives in question (sorry I worded that incorrectly initially), or so >> I've been told (this information is second-hand). > > So, noop scheduler, then?
Yes, "elevator=noop" on both sides. Again, sorry to be unclear about that. > > Under noop, the block layer will send requests as soon as it can without > merging. If it has more requests outstanding than the queue length on > the SRP initiator, then it will merge the new request with the queued > ones if possible. So, noop will merge requests when the queue is full, but not hold-off to merge? <snip> > > The SRP initiator just hands off requests as quick as they are sent to > it by the block layer. You can control how big those requests are by > tuning /sys/block/$DEV/queue/max_sectors_kb up to .../max_hw_sectors_kb > which gets set by the max_sect parameter when adding the SRP target. So the block layer may also hold-off on small requests, and decreasing max_sectors_kb will force it to flush to the SRP initiator ASAP (or is this just used for fragmentation of large requests)? Note that 'm trying to minimize latency for very small requests. Thanks, Chris -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
