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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jan 12 2018 at  8:00pm -0500,
Bart Van Assche <Bart.VanAssche@xxxxxxx> 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@xxxxxxxxxxx>
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@xxxxxxxxxxxxxxx # 4.9+
    Signed-off-by: Bart Van Assche <bart.vanassche@xxxxxxxxxxx>
    Signed-off-by: Mike Snitzer <snitzer@xxxxxxxxxx>

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.

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel



[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux