On Fri, Oct 14, 2011 at 12:16 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > We already do an explicit sleep in transport_tcq_window_closed if > we exhaust the queue depth. Note that the code doing that is fairly > non-optimal as it simply does an msleep in whatever context it is > called, which might either be the fabrics thread calling in the first > time, or the main transport processing thread (which also handles I/O > completions). Having one common way to handle this would be good, > but simply doing a context switch without explicit delay isn't going > to help you anything. On a lightly loadeded SMP systems the context > switch is basically not noticable in the grander scheme of things. Right, but that explicit sleep really has to go in the long term. The problem is that if we have a backend that can has high performance, we can go from queue full to queue empty in way less time than we sleep for, which means that we stall processing and get way worse performance than the backend can do. I don't know how to fit this into the target stack architecture, but in vague terms we need to stop processing when the queue is full, and then restart processing when there's queue space available (maybe not when the first slot opens up, but say when we have half the queue available again). - R. -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
