On Tue, Jan 16 2007, Eric D. Mudama wrote: [snip lots of stuff I agree completely with] > If done properly, queueing should never hurt performance. High queue > depths will increase average latency of course, but shouldn't hurt > overall performance. It may never hurt performance, but there are common scenarios where you are much better off not doing queuing even if you could. A good example of that is a media serving service, where you end up reading a bunch of files sequentially. It's faster to read chunks of each file sequentially at depth 1 and move on, than queue a a request from each of them and send them to the drive. On my laptop with an NCQ enabled drive, the mentioned approach outperforms queuing by more than 100%. > >NCQ mainly helps with multiple threads doing reads. Writes are > >largely asynchronous to the user already (except for fsync-style > >writes). You want to be able to stuff the disk's internal elevator > >with as many read requests as possible, because reads are very often > >synchronous -- most apps (1) read a block, (2) do something, (3) goto > >step #1. The kernel's elevator isn't much use in these cases. > > True. And internal to the drive, normal elevator is "meh." There are > other algorithms for scheduling that perform better. Well Linux doesn't default to using a normal elevator, so it's a moot point. -- Jens Axboe - 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
