Re: [PATCH V3 0/5] dm-rq: improve sequential I/O performance

[Mike Snitzer <snitzer@redhat.com>]

On Fri, Jan 12 2018 at  8:37pm -0500,
Mike Snitzer <snitzer@redhat.com> wrote:

> On Fri, Jan 12 2018 at  8:00pm -0500,
> Bart Van Assche <Bart.VanAssche@wdc.com> wrote:
> 
> > On Fri, 2018-01-12 at 19:52 -0500, Mike Snitzer wrote:
> > > It was 50 ms before it was 100 ms.  No real explaination for these
> > > values other than they seem to make Bart's IB SRP testbed happy?
> > 
> > But that constant was not introduced by me in the dm code.
> 
> No actually it was (not that there's anything wrong with that):
> 
> commit 06eb061f48594aa369f6e852b352410298b317a8
> Author: Bart Van Assche <bart.vanassche@sandisk.com>
> Date:   Fri Apr 7 16:50:44 2017 -0700
> 
>     dm mpath: requeue after a small delay if blk_get_request() fails
> 
>     If blk_get_request() returns ENODEV then multipath_clone_and_map()
>     causes a request to be requeued immediately. This can cause a kworker
>     thread to spend 100% of the CPU time of a single core in
>     __blk_mq_run_hw_queue() and also can cause device removal to never
>     finish.
> 
>     Avoid this by only requeuing after a delay if blk_get_request() fails.
>     Additionally, reduce the requeue delay.
> 
>     Cc: stable@vger.kernel.org # 4.9+
>     Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
>     Signed-off-by: Mike Snitzer <snitzer@redhat.com>
> 
> Note that this commit actually details a different case where a
> blk_get_request() (in existing code) return of -ENODEV is a very
> compelling case to use DM_MAPIO_DELAY_REQUEUE.
> 
> SO I'll revisit what is appropriate in multipath_clone_and_map() on
> Monday.

Sleep helped.  I had another look and it is only the old .request_fn
blk_get_request() code that even sets -ENODEV (if blk_queue_dying).

But thankfully the blk_get_request() error handling in
multipath_clone_and_map() checks for blk_queue_dying() and will return
DM_MAPIO_DELAY_REQUEUE.

So we're all set for this case.

Mike