On Mon, Dec 19, 2011 at 1:49 PM, Tejun Heo <tj@xxxxxxxxxx> wrote: > Hello, > > On Fri, Dec 16, 2011 at 06:33:18PM -0800, Dan Williams wrote: >> commit 9c5a2ba7 "workqueue: separate out drain_workqueue() from >> destroy_workqueue()" provided drain_workqueue() for users like libsas to >> use for flushing events. >> >> When libsas drains it wants currently queued and chained events to be >> flushed, but it fully expects to continue issuing unchained events with >> the expectation that they are serviced sometime after the drain. >> >> For external users of drain_workqueue() arrange for unchained work to be >> queued after the drain completes, if the caller cares if unchained work >> was queued as a result of the drain it can check for a non-zero return >> value. Deferred work is guaranteed to be at least queued when >> drain_workqueue() returns, and visible to flush_workqueue() users as >> well. >> >> Unfortunately this causes the promotion of workqueue_lock to hard-irq >> safe and does not guarantee that work submitted via queue_work_on() runs >> on the specified cpu if it gets deferred. >> >> Cc: Tejun Heo <tj@xxxxxxxxxx> >> Signed-off-by: Dan Williams <dan.j.williams@xxxxxxxxx> > > Dan, as I replied before, I'm not a big fan of this approach. Sorry I must have missed it, I can't seem to find a reply in the archives? > For > now, I think it would be best to add private wrapper in libsas to > support deferring unchained work items while draining. Ok, a form of this was nak'd by James before [1], but I can try again with pushing this chained submission checking down into scsi. -- Dan [1]: http://marc.info/?l=linux-scsi&m=130655248916967&w=2 -- 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
