Messages in this thread | | | From | Jeff Moyer <> | Subject | Re: [patch] block: fix flush machinery for stacking drivers with differring flush flags | Date | Fri, 12 Aug 2011 13:01:18 -0400 |
| |
Shaohua Li <shli@kernel.org> writes:
> 2011/8/10 Jeff Moyer <jmoyer@redhat.com>: >> @@ -320,6 +319,7 @@ void blk_insert_flush(struct request *rq) >> if ((policy & REQ_FSEQ_DATA) && >> !(policy & (REQ_FSEQ_PREFLUSH | REQ_FSEQ_POSTFLUSH))) { >> list_add_tail(&rq->queuelist, &q->queue_head); >> + blk_run_queue_async(q); > A minor issue. I can understand this is required for > blk_insert_cloned_request() because INSERT_BACK will run > queue but INSERT_FLUSH doesn't. But sounds we don't need > run queue for normal requests. Either __make_request will run > queue (task has plug list) or flush_plug will run queue. delaying > run queue has its benefit. can we do the runqueue in > blk_insert_cloned_request() if this is a INSERT_FLUSH.
Well, the only time we need to run the queue is when the request has data, has REQ_FUA set, and the underlying queue's flush flags contain only REQ_FUA. In code:
if (rq->cmd_flags & REQ_FUA && q->flush_flags == REQ_FUA) blk_run_queue_async(q);
If that was added to blk_insert_cloned_request, we could get rid of the blk_run_queue_async in blk_insert_flush. However, I think Tejun will object due to the layering violation for the same reason he doesn't like my handling of empty flushes in blk_insert_cloned_request.
Tejun?
Cheers, Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |