On Mon, 2011-10-17 at 13:56 -0400, Christoph Hellwig wrote: > This series starts converting the target core to use workqueues instead > of a single processing thread per device. The first conversion is > for the I/O completions for the backend drivers, as these are much > easier without having to deal with HEAD OF QUEUE attributes and similar. > > The actual conversion is the last patch, and the rest is preparation > that I stumbled over while doing this work. Most notable the first > two change the per-command QUEUE FULL handling in a slightly less agressive > way than my previous attempt. I've been running this with tcm_loop, qla2xxx and iscsi-target on -rc10 and so far so good.. One thing i've noticed with tcm_qla2xxx using the new workqueue based completion logic is that tcm_qla2xxx_release_cmd() (called from TRANSPORT_FREE_CMD_INTR context) is having to wait on qla_tgt_cmd->cmd_stop_free_comp once every few seconds during sustained I/O while tcm_qla2xxx_check_stop_free() finishes running from transport_cmd_check_stop() -> TFO->check_stop_free() in workqueue context. This is the case where a HW fabric module is able to send a response via TFO->queue_[data_in,status](), receive an acknowledgement, and call transport_generic_free_cmd() before target_complete_ok_work() -> transport_cmd_check_stop() has been called. The main problem here is still transport_cmd_check_stop() doing all the active shutdown I/O accounting + taking too long, causing the transport_generic_free_cmd() path to have to sometimes do the extra wait + context switch for it's completion. I don't have a good idea how to completely resolve this inefficiency yet w/o completely breaking the active I/O shutdown logic, but at least pushing it out of fabric modules and into target-core generic code is something that we should consider for the short term.. tcm_qla2xxx and ib_srpt are the two that do internal checking to make sure descriptors are not released before TFO->check_stop_free() has been called, but I don't see a reason why this can't be made common.. --nab -- 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
