Hello Ming,
Can you have a look at the attached patch? That patch uses an srcu read
lock for all queue types, whether or not the BLK_MQ_F_BLOCKING flag has
been set. Additionally, I have dropped the QUEUE_FLAG_QUIESCING flag.
Just like previous versions, this patch has been tested.
Hey Bart,
Do we care about the synchronization of queue_rq and/or
blk_mq_run_hw_queue of the hctx is not stopped?
I'm wandering if we can avoid introducing new barriers in the
submission path of its not absolutely needed.
Hello Sagi,
Hey Bart,
I'm not sure whether the new blk_quiesce_queue() function is useful
without stopping all hardware contexts first. In other words, in my view
setting BLK_MQ_F_BLOCKING flag before calling blk_quiesce_queue() is
sufficient and I don't think that a new QUEUE_FLAG_QUIESCING flag is
necessary.
I was referring to weather we can take srcu in the submission path
conditional of the hctx being STOPPED?
--
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
