On Fri, 2017-09-01 at 11:02 +0800, Ming Lei wrote: > That is a good question, but it has been answered by the comment > before checking the DISPATCH_BUSY state in blk_mq_sched_dispatch_requests(): > > /* > * If DISPATCH_BUSY is set, that means hw queue is busy > * and requests in the list of hctx->dispatch need to > * be flushed first, so return early. > * > * Wherever DISPATCH_BUSY is set, blk_mq_run_hw_queue() > * will be run to try to make progress, so it is always > * safe to check the state here. > */ > > Suppose the two writes are reordered, sooner or latter, the > list_empty_careful(&hctx->dispatch) will be observed, and > will dispatch request from this hw queue after '->dispatch' > is flushed. > > Since now the setting of DISPATCH_BUSY requires to hold > hctx->lock, we should avoid to add barrier there.
Although it is not clear to me how anyone who has not followed this discussion is assumed to figure out all these subtleties, if the other comments get addressed: Reviewed-by: Bart Van Assche <bart.vanass...@wdc.com>
