diff for duplicates of <1492189969.2644.9.camel@sandisk.com> diff --git a/a/1.txt b/N1/1.txt index 54ae66b..63b90d0 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -2,33 +2,39 @@ On Fri, 2017-04-14 at 09:13 +0800, Ming Lei wrote: > On Thu, Apr 13, 2017 at 09:59:57AM -0700, Bart Van Assche wrote: > > On 04/12/17 19:20, Ming Lei wrote: > > > On Wed, Apr 12, 2017 at 06:38:07PM +0000, Bart Van Assche wrote: -> > > > If the blk-mq core would always rerun a hardware queue if a block driver -> > > > returns BLK_MQ_RQ_QUEUE_BUSY then that would cause 100% of a single CPU core -> > > -> > > It won't casue 100% CPU utilization since we restart queue in completion -> > > path and at that time at least one tag is available, then progress can be +> > > > If the blk-mq core would always rerun a hardware queue if a block d= +river +> > > > returns BLK_MQ_RQ_QUEUE_BUSY then that would cause 100% of a single= + CPU core +> > >=20 +> > > It won't casue 100% CPU utilization since we restart queue in complet= +ion +> > > path and at that time at least one tag is available, then progress ca= +n be > > > made. -> > +> >=20 > > Hello Ming, -> > +> >=20 > > Sorry but you are wrong. If .queue_rq() returns BLK_MQ_RQ_QUEUE_BUSY > > then it's likely that calling .queue_rq() again after only a few > > microseconds will cause it to return BLK_MQ_RQ_QUEUE_BUSY again. If you > > don't believe me, change "if (!blk_mq_sched_needs_restart(hctx) && -> > !test_bit(BLK_MQ_S_TAG_WAITING, &hctx->state)) blk_mq_run_hw_queue(hctx, +> > !test_bit(BLK_MQ_S_TAG_WAITING, &hctx->state)) blk_mq_run_hw_queue(hctx= +, > > true);" into "blk_mq_run_hw_queue(hctx, true);", trigger a busy -> +>=20 > Yes, that can be true, but I mean it is still OK to run the queue again > with -> +>=20 > if (!blk_mq_sched_needs_restart(hctx) && > !test_bit(BLK_MQ_S_TAG_WAITING, &hctx->state)) > blk_mq_run_hw_queue(hctx, true); -> +>=20 > and restarting queue in __blk_mq_finish_request() when -> BLK_MQ_RQ_QUEUE_BUSY is returned from .queue_rq(). And both are in current +> BLK_MQ_RQ_QUEUE_BUSY is returned from .queue_rq(). And both are in curren= +t > blk-mq implementation. -> +>=20 > Then why do we need blk_mq_delay_run_hw_queue(hctx, 100/*ms*/) in dm? Because if dm_mq_queue_rq() returns BLK_MQ_RQ_QUEUE_BUSY that there is no @@ -37,4 +43,4 @@ same queue. dm_mq_queue_rq() can e.g. return BLK_MQ_RQ_QUEUE_BUSY while no dm requests are in progress because the SCSI error handler is active for all underlying paths. See also scsi_lld_busy() and scsi_host_in_recovery(). -Bart. +Bart.= diff --git a/a/content_digest b/N1/content_digest index d4e308f..517e9e3 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -24,33 +24,39 @@ "> On Thu, Apr 13, 2017 at 09:59:57AM -0700, Bart Van Assche wrote:\n" "> > On 04/12/17 19:20, Ming Lei wrote:\n" "> > > On Wed, Apr 12, 2017 at 06:38:07PM +0000, Bart Van Assche wrote:\n" - "> > > > If the blk-mq core would always rerun a hardware queue if a block driver\n" - "> > > > returns BLK_MQ_RQ_QUEUE_BUSY then that would cause 100% of a single CPU core\n" - "> > > \n" - "> > > It won't casue 100% CPU utilization since we restart queue in completion\n" - "> > > path and at that time at least one tag is available, then progress can be\n" + "> > > > If the blk-mq core would always rerun a hardware queue if a block d=\n" + "river\n" + "> > > > returns BLK_MQ_RQ_QUEUE_BUSY then that would cause 100% of a single=\n" + " CPU core\n" + "> > >=20\n" + "> > > It won't casue 100% CPU utilization since we restart queue in complet=\n" + "ion\n" + "> > > path and at that time at least one tag is available, then progress ca=\n" + "n be\n" "> > > made.\n" - "> > \n" + "> >=20\n" "> > Hello Ming,\n" - "> > \n" + "> >=20\n" "> > Sorry but you are wrong. If .queue_rq() returns BLK_MQ_RQ_QUEUE_BUSY\n" "> > then it's likely that calling .queue_rq() again after only a few\n" "> > microseconds will cause it to return BLK_MQ_RQ_QUEUE_BUSY again. If you\n" "> > don't believe me, change \"if (!blk_mq_sched_needs_restart(hctx) &&\n" - "> > !test_bit(BLK_MQ_S_TAG_WAITING, &hctx->state)) blk_mq_run_hw_queue(hctx,\n" + "> > !test_bit(BLK_MQ_S_TAG_WAITING, &hctx->state)) blk_mq_run_hw_queue(hctx=\n" + ",\n" "> > true);\" into \"blk_mq_run_hw_queue(hctx, true);\", trigger a busy\n" - "> \n" + ">=20\n" "> Yes, that can be true, but I mean it is still OK to run the queue again\n" "> with\n" - "> \n" + ">=20\n" "> \tif (!blk_mq_sched_needs_restart(hctx) &&\n" "> \t !test_bit(BLK_MQ_S_TAG_WAITING, &hctx->state))\n" "> \t\t\tblk_mq_run_hw_queue(hctx, true);\n" - "> \n" + ">=20\n" "> and restarting queue in __blk_mq_finish_request() when\n" - "> BLK_MQ_RQ_QUEUE_BUSY is returned from .queue_rq(). And both are in current\n" + "> BLK_MQ_RQ_QUEUE_BUSY is returned from .queue_rq(). And both are in curren=\n" + "t\n" "> blk-mq implementation.\n" - "> \n" + ">=20\n" "> Then why do we need blk_mq_delay_run_hw_queue(hctx, 100/*ms*/) in dm?\n" "\n" "Because if dm_mq_queue_rq() returns BLK_MQ_RQ_QUEUE_BUSY that there is no\n" @@ -59,6 +65,6 @@ "dm requests are in progress because the SCSI error handler is active for\n" "all underlying paths. See also scsi_lld_busy() and scsi_host_in_recovery().\n" "\n" - Bart. + Bart.= -1eb57d0dcb46ed8bb9fe017e19e2ca0d271975db5dce5a19f98a035eda305034 +7996826ffa5adbe06eb12d0a79de1272d3cdc9f538fd6e6e0481708c0040694b
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.