On Fri, Aug 06, 2010 at 10:38:46PM +0400, Vladislav Bolkhovitin wrote: > Are there still any people thinking that tagged queuing doesn't have any > meaningful use? > > Or 350% performance increase doesn't matter? (If the system was more > powerful, the difference would be even bigger.) > > As you can see on external storage even with 128K commands the queue > should have at least 2 entries queued to go with full performance. Vlad, no one disagrees that draining the queue is really bad for performance. That's in fact what started the whole thread. The question is wether it's worth to deal with the complexities of using tagged queing all the way through the I/O and filesystem stack, or wether to keep the existing perfectly working code to wait on individual I/O requests in the filesystem. The latter won't be able to keep the queue filled for the case where we try to max out the I/O subsystem with a single synchronous writer thread, so tagged queueing would be a clear win for that. It's not exactly the typical use case for high end storage, though - and once you have multiple threads keeping the queue busy the advantage of the tagging shrinks. Of course all this is just talking and someone would need to actually do the work of using tagged queueing in a useful (and non-buggy) way and benchmark it. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
