From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 24 Jan 2018 00:59:15 +0800 From: Ming Lei To: Bart Van Assche Cc: "linux-block@vger.kernel.org" , "hch@infradead.org" , "snitzer@redhat.com" , "martin.petersen@oracle.com" , "axboe@kernel.dk" , "linux-scsi@vger.kernel.org" , "jejb@linux.vnet.ibm.com" , "loberman@redhat.com" , "dm-devel@redhat.com" Subject: Re: [PATCH 1/5] blk-mq: introduce BLK_STS_DEV_RESOURCE Message-ID: <20180123165914.GH13277@ming.t460p> References: <20180122033550.27855-2-ming.lei@redhat.com> <1516639793.2545.14.camel@sandisk.com> <20180123005728.GB4411@ming.t460p> <54f0c19c-38aa-e788-f476-492e5a5734c9@wdc.com> <20180123162605.GD13277@ming.t460p> <4cdb2b42-0097-c64a-d9c0-b7a1727c80de@wdc.com> <20180123164109.GF13277@ming.t460p> <1516726030.3339.14.camel@wdc.com> <20180123164951.GG13277@ming.t460p> <1516726441.3339.16.camel@wdc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <1516726441.3339.16.camel@wdc.com> List-ID: On Tue, Jan 23, 2018 at 04:54:02PM +0000, Bart Van Assche wrote: > On Wed, 2018-01-24 at 00:49 +0800, Ming Lei wrote: > > On Tue, Jan 23, 2018 at 04:47:11PM +0000, Bart Van Assche wrote: > > > On Wed, 2018-01-24 at 00:41 +0800, Ming Lei wrote: > > > > Could you explain where to call call_rcu()? call_rcu() can't be used in > > > > IO path at all. > > > > > > Can you explain what makes you think that call_rcu() can't be used in the > > > I/O path? As you know call_rcu() invokes a function asynchronously. From > > > Documentation/RCU/Design/Requirements/Requirements.html: > > > > > > The call_rcu() function may be used in a number of > > > situations where neither synchronize_rcu() nor > > > synchronize_rcu_expedited() would be legal, > > > including within preempt-disable code, local_bh_disable() code, > > > interrupt-disable code, and interrupt handlers. > > > > OK, suppose it is true, do you want to change most of STS_RESOURCE in > > all drivers to this way? Why can't we use the generic and simple approach > > in this patch? > > Please reread my proposal. I did not propose to change any block drivers. > What I proposed is to change the blk_mq_delay_run_hw_queue() implementation > such that it uses call_rcu() instead of kblockd_mod_delayed_work_on(). > That's a generic and simple approach. How is that enough to fix the IO hang when driver returns STS_RESOURCE and the queue is idle? If you want to follow previous dm-rq's way of call blk_mq_delay_run_hw_queue() in .queue_rq(), the same trick need to be applied to other drivers too, right? Unfortunately most of STS_RESOURCE don't use this trick, but they need to be handled. The patch of 'blk-mq: introduce BLK_STS_DEV_RESOURCE' can fix all these cases. -- Ming