On Wed, Sep 20, 2017 at 11:26:09PM +0000, Bart Van Assche wrote: > On Thu, 2017-09-21 at 06:36 +0800, Ming Lei wrote: > > Actually with GFP_ATOMIC, dispatch in dm-rq can't move on and no request > > will be dequeued from IO scheduler queue if this allocation fails, that > > means IO merge is still working at that time if the patchset of > > 'blk-mq-sched: improve SCSI-MQ performance' is applied. > > > > As my test done, the sequential I/O performance is still not good > > even though the patchset is applied. > > > > That isn't strange because queue depth of IO scheduler queue can be > > much bigger than either q->queue_depth or .cmd_per_lun, that means > > the underlying queue has been busy for a while before the allocation > > fails. > > Hello Ming, > > This patch is intended as an alternative for your patch series "dm-mpath: > improve I/O schedule". I wanted to show that it is possible to reduce Hi Bart, As I explained, this patch can't fix the I/O merge issue since it is easy to trigger queue busy before running out of requests, that is why I changes the 'nr_request' in the patch 5 of 'dm-mpath: improve I/O schedule'. > dm-mpath request submission latency if the underlying driver returns > "busy" frequently without touching the "return DM_MAPIO_DELAY_REQUEUE" I already explained, the DM_MAPIO_DELAY_REQUEUE can be changed to DM_MAPIO_REQUEUE at least for dm-rq-mq via SCHED_RESTART, even for dm-rq-sq, it should be possible but need to make sure there is in-flight requests because we run queue in rq_completed(). -- Ming -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
