Re: [PATCH v4 6/6] dm rq: Avoid that request processing stalls sporadically

2017-04-16 Thread Ming Lei
On Fri, Apr 14, 2017 at 05:12:50PM +, Bart Van Assche wrote: > 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 +, Bart Van Assche wrote

Re: [PATCH v4 6/6] dm rq: Avoid that request processing stalls sporadically

2017-04-14 Thread Bart Van Assche
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 +, Bart Van Assche wrote: > > > > If the blk-mq core would always rerun a hardware queue if a blo

Re: [PATCH v4 6/6] dm rq: Avoid that request processing stalls sporadically

2017-04-13 Thread Ming Lei
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 +, 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

Re: [PATCH v4 6/6] dm rq: Avoid that request processing stalls sporadically

2017-04-13 Thread Bart Van Assche
On 04/12/17 19:20, Ming Lei wrote: > On Wed, Apr 12, 2017 at 06:38:07PM +, 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

Re: [PATCH v4 6/6] dm rq: Avoid that request processing stalls sporadically

2017-04-12 Thread Ming Lei
On Wed, Apr 12, 2017 at 06:38:07PM +, Bart Van Assche wrote: > On Wed, 2017-04-12 at 11:42 +0800, Ming Lei wrote: > > On Tue, Apr 11, 2017 at 06:18:36PM +, Bart Van Assche wrote: > > > On Tue, 2017-04-11 at 14:03 -0400, Mike Snitzer wrote: > > > > Rather than working so hard to use DM code

Re: [PATCH v4 6/6] dm rq: Avoid that request processing stalls sporadically

2017-04-12 Thread Bart Van Assche
On Wed, 2017-04-12 at 11:42 +0800, Ming Lei wrote: > On Tue, Apr 11, 2017 at 06:18:36PM +, Bart Van Assche wrote: > > 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 rer

Re: [PATCH v4 6/6] dm rq: Avoid that request processing stalls sporadically

2017-04-11 Thread Ming Lei
On Tue, Apr 11, 2017 at 06:18:36PM +, Bart Van Assche wrote: > 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" >

Re: [PATCH v4 6/6] dm rq: Avoid that request processing stalls sporadically

2017-04-11 Thread Bart Van Assche
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" > > I see drivers/nvme/host/fc.c:nvme_fc_start_fcp_op() does. But that is

Re: [PATCH v4 6/6] dm rq: Avoid that request processing stalls sporadically

2017-04-11 Thread Mike Snitzer
On Tue, Apr 11 2017 at 1:51pm -0400, Bart Van Assche wrote: > On Tue, 2017-04-11 at 13:47 -0400, Mike Snitzer wrote: > > Other drivers will very likely be caught about by > > this blk-mq quirk in the future. > > Hello Mike, > > Are you aware that the requirement that blk-mq drivers rerun the q

Re: [PATCH v4 6/6] dm rq: Avoid that request processing stalls sporadically

2017-04-11 Thread Bart Van Assche
On Tue, 2017-04-11 at 13:47 -0400, Mike Snitzer wrote: > Other drivers will very likely be caught about by > this blk-mq quirk in the future. Hello Mike, Are you aware that the requirement that blk-mq drivers rerun the queue after having returned BLK_MQ_RQ_QUEUE_BUSY is a requirement that is shar

Re: [PATCH v4 6/6] dm rq: Avoid that request processing stalls sporadically

2017-04-11 Thread Mike Snitzer
On Tue, Apr 11 2017 at 12:26pm -0400, Bart Van Assche wrote: > On Tue, 2017-04-11 at 12:09 -0400, Mike Snitzer wrote: > > This has no place in dm-mq (or any blk-mq > > driver). If it is needed it should be elevated to blk-mq core to > > trigger blk_mq_delay_run_hw_queue() when BLK_MQ_RQ_QUEUE_BU

Re: [PATCH v4 6/6] dm rq: Avoid that request processing stalls sporadically

2017-04-11 Thread Bart Van Assche
On Tue, 2017-04-11 at 12:09 -0400, Mike Snitzer wrote: > This has no place in dm-mq (or any blk-mq > driver). If it is needed it should be elevated to blk-mq core to > trigger blk_mq_delay_run_hw_queue() when BLK_MQ_RQ_QUEUE_BUSY is > returned from blk_mq_ops' .queue_rq. Hello Mike, If the blk-m

Re: [PATCH v4 6/6] dm rq: Avoid that request processing stalls sporadically

2017-04-11 Thread Mike Snitzer
On Fri, Apr 07 2017 at 2:16pm -0400, Bart Van Assche wrote: > While running the srp-test software I noticed that request > processing stalls sporadically at the beginning of a test, namely > when mkfs is run against a dm-mpath device. Every time when that > happened the following command was suf

[PATCH v4 6/6] dm rq: Avoid that request processing stalls sporadically

2017-04-07 Thread Bart Van Assche
While running the srp-test software I noticed that request processing stalls sporadically at the beginning of a test, namely when mkfs is run against a dm-mpath device. Every time when that happened the following command was sufficient to resume request processing: echo run >/sys/kernel/debug/