Shaohua Li <shli@xxxxxxxxxx> writes:
> 2011/8/10 Jeff Moyer <jmoyer@xxxxxxxxxx>:
>> @@ -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
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
