On Mon, Dec 12, 2011 at 6:09 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > [ 968.116635] [<ffffffff8175465c>] transport_processing_thread+0x13c/0x4a0 If you look at transport_processing_thread(), you'll notice that the only time it goes to sleep in wait_event is if dev->dev_queue_obj.queue_cnt is 0. So as long as there is work being queued up, the thread will continue to run, even for the 22s you saw in your soft lockup report. Locally we are using a hack that adds a cond_resched() if the thread has been running for 2 seconds -- we found that performance regressed if we just did a cond_resched() every iteration. Which is a bad sign -- it means our current performance depends on the processing threads taking more than the share the scheduler thinks they should get. So this isn't a final solution, more just a hack.... - 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
