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

[Mike Snitzer <snitzer@redhat.com>]

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.

I need a break... have a good weekend Bart.