On Fri, Apr 12, 2013 at 12:42 PM, Ren Mingxin <renmx@xxxxxxxxxxxxxx> wrote: > > Please let me summarize what this thread has talked about the scsi > eh latency: > > 1) some scsi cmds' timemout values are inappropriate, we can avoid > timeout by: > a) sg_format sets the IMMED bit and use TEST UNIT READY or REQUEST > SENSE polling to monitor - by Douglas > b) cut big cmd into some reasonable-sized ones - by Douglas > c) improve timeout values according to device types - by Elliott > 2) call ->done() on the command after lun reset - by Hannes > > And, my question is: > - could we wake up eh thread ASAP instead of waiting for all cmds > complete to fast scheduling? > > BTW: my original question is here: > http://www.spinics.net/lists/linux-scsi/msg65107.html I don't think you can just do this simple change of not waiting for all commands to timeout. The problem will start when your abort will fail and you'll be forced to do the higher level actions such as target reset, since it will take out all active requests you'll want to wait for all active requests to either return or timeout and for that time you want to also not send any new commands down the pipe. Ofcourse, there are situations where you don't care enough about the other commands and can handle their cancellation with an immediate target reset or you may even just prefer to not even abort that single command. I've seen and implemented changes (internal to my employer) to do just that but the changes to the code are non-trivial. Baruch -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
