On 09/07/2016 06:41 PM, Mike Snitzer wrote:
On Fri, Sep 02 2016 at 6:42pm -0400,
Bart Van Assche <bart.vanassche@xxxxxxxxxxx> wrote:
+/**
+ * blk_mq_quiesce_queue - wait until all pending queue_rq calls have finished
+ *
+ * Prevent that new I/O requests are queued and wait until all pending
+ * queue_rq() calls have finished.
+ */
+void blk_mq_quiesce_queue(struct request_queue *q)
+{
+ spin_lock_irq(q->queue_lock);
+ WARN_ON_ONCE(blk_queue_quiescing(q));
+ queue_flag_set(QUEUE_FLAG_QUIESCING, q);
+ spin_unlock_irq(q->queue_lock);
+
+ atomic_inc_return(&q->mq_freeze_depth);
+ blk_mq_run_hw_queues(q, false);
+ synchronize_rcu();
Why the synchronize_rcu()?
Hello Mike,
Adding read_lock() + read_unlock() in __blk_mq_run_hw_queue() and
synchronize_rcu() in blk_mq_quiesce_queue() is the lowest overhead
mechanism I know of to make the latter function wait until the former
has finished.
Also, you're effectively open-coding blk_mq_freeze_queue_start() minus
the q->q_usage_counter mgmt. Why not add a flag to conditionally manage
q->q_usage_counter to blk_mq_freeze_queue_start()?
I will consider this.
But I'm concerned about blk_mq_{quiesce,resume}_queue vs
blk_mq_{freeze,unfreeze}_queue -- e.g. if "freeze" is nested after
"queue" (but before "resume") it would still need the q->q_usage_counter
management. Your patch as-is would break the blk-mq freeze interface.
Agreed. blk_mq_{quiesce,resume}_queue() has to manipulate
q_usage_counter in the same way as blk_mq_{freeze,unfreeze}_queue().
Once I am back in the office I will rework this patch and send it to Jens.
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
