Re: [RFC PATCH 0/3] blk-mq: Timeout rework

2018-05-22 Thread Keith Busch
On Tue, May 22, 2018 at 04:30:41PM +, Bart Van Assche wrote: > > Please have a look at v13 of the timeout handling rework patch that I posted. > That patch should not introduce any new race conditions and should also handle > the scenario fine in which blk_mq_complete_request() is called

Re: [RFC PATCH 0/3] blk-mq: Timeout rework

2018-05-22 Thread Bart Van Assche
On Tue, 2018-05-22 at 08:06 -0600, Keith Busch wrote: > On Mon, May 21, 2018 at 11:29:21PM +, Bart Van Assche wrote: > > Can you explain why the NVMe driver needs reference counting of requests but > > no other block driver needs this? Additionally, why is it that for all block > > drivers

Re: [RFC PATCH 0/3] blk-mq: Timeout rework

2018-05-22 Thread Keith Busch
On Mon, May 21, 2018 at 11:29:21PM +, Bart Van Assche wrote: > Can you explain why the NVMe driver needs reference counting of requests but > no other block driver needs this? Additionally, why is it that for all block > drivers except NVMe the current block layer API is sufficient >

Re: [RFC PATCH 0/3] blk-mq: Timeout rework

2018-05-21 Thread Bart Van Assche
On Mon, 2018-05-21 at 17:11 -0600, Keith Busch wrote: > The current blk-mq code potentially locks requests out of completion by > the thousands, making drivers jump through hoops to handle them. This > patch set allows drivers to complete their requests whenever they're > completed without

[RFC PATCH 0/3] blk-mq: Timeout rework

2018-05-21 Thread Keith Busch
The current blk-mq code potentially locks requests out of completion by the thousands, making drivers jump through hoops to handle them. This patch set allows drivers to complete their requests whenever they're completed without requiring drivers know anything about the timeout code with minimal