diff for duplicates of <1491934715.2654.14.camel@sandisk.com> diff --git a/a/1.txt b/N1/1.txt index a6f57b8..f241069 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -2,23 +2,29 @@ On Tue, 2017-04-11 at 14:03 -0400, Mike Snitzer wrote: > Rather than working so hard to use DM code against me, your argument > should be: "blk-mq drivers X, Y and Z rerun the hw queue; this is a well > established pattern" -> +>=20 > I see drivers/nvme/host/fc.c:nvme_fc_start_fcp_op() does. But that is > only one other driver out of ~20 BLK_MQ_RQ_QUEUE_BUSY returns > tree-wide. -> +>=20 > Could be there are some others, but hardly a well-established pattern. Hello Mike, Several blk-mq drivers that can return BLK_MQ_RQ_QUEUE_BUSY from their -.queue_rq() implementation stop the request queue (blk_mq_stop_hw_queue()) +.queue_rq() implementation stop the request queue=A0(blk_mq_stop_hw_queue()= +) before returning "busy" and restart the queue after the busy condition has -been cleared (blk_mq_start_stopped_hw_queues()). Examples are virtio_blk and +been cleared (blk_mq_start_stopped_hw_queues()). Examples are virtio_blk an= +d xen-blkfront. However, this approach is not appropriate for the dm-mq core -nor for the scsi core since both drivers already use the "stopped" state for -another purpose than tracking whether or not a hardware queue is busy. Hence -the blk_mq_delay_run_hw_queue() and blk_mq_run_hw_queue() calls in these last -two drivers to rerun a hardware queue after the busy state has been cleared. +nor for the scsi core since both drivers already use the "stopped" state fo= +r +another purpose than tracking whether or not a hardware queue is busy. Henc= +e +the blk_mq_delay_run_hw_queue() and blk_mq_run_hw_queue() calls in these la= +st +two drivers to rerun a hardware queue after the busy state has been cleared= +. -Bart. +Bart.= diff --git a/a/content_digest b/N1/content_digest index 2fa0eee..47af593 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -19,25 +19,31 @@ "> Rather than working so hard to use DM code against me, your argument\n" "> should be: \"blk-mq drivers X, Y and Z rerun the hw queue; this is a well\n" "> established pattern\"\n" - "> \n" + ">=20\n" "> I see drivers/nvme/host/fc.c:nvme_fc_start_fcp_op() does. But that is\n" "> only one other driver out of ~20 BLK_MQ_RQ_QUEUE_BUSY returns\n" "> tree-wide.\n" - "> \n" + ">=20\n" "> Could be there are some others, but hardly a well-established pattern.\n" "\n" "Hello Mike,\n" "\n" "Several blk-mq drivers that can return BLK_MQ_RQ_QUEUE_BUSY from their\n" - ".queue_rq() implementation stop the request queue\302\240(blk_mq_stop_hw_queue())\n" + ".queue_rq() implementation stop the request queue=A0(blk_mq_stop_hw_queue()=\n" + ")\n" "before returning \"busy\" and restart the queue after the busy condition has\n" - "been cleared (blk_mq_start_stopped_hw_queues()). Examples are virtio_blk and\n" + "been cleared (blk_mq_start_stopped_hw_queues()). Examples are virtio_blk an=\n" + "d\n" "xen-blkfront. However, this approach is not appropriate for the dm-mq core\n" - "nor for the scsi core since both drivers already use the \"stopped\" state for\n" - "another purpose than tracking whether or not a hardware queue is busy. Hence\n" - "the blk_mq_delay_run_hw_queue() and blk_mq_run_hw_queue() calls in these last\n" - "two drivers to rerun a hardware queue after the busy state has been cleared.\n" + "nor for the scsi core since both drivers already use the \"stopped\" state fo=\n" + "r\n" + "another purpose than tracking whether or not a hardware queue is busy. Henc=\n" + "e\n" + "the blk_mq_delay_run_hw_queue() and blk_mq_run_hw_queue() calls in these la=\n" + "st\n" + "two drivers to rerun a hardware queue after the busy state has been cleared=\n" + ".\n" "\n" - Bart. + Bart.= -5cd1fb1319895b2984a94c806b1344121a5b8d3d4774fe1ecf7f4f09431d9639 +3f11227f4817fb42ec892e0f4bb9c034d79ec65e5661bdd096d5e2257c34a6c9
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.