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 dm-mpath request submission latency if the underlying driver returns "busy" frequently without touching the "return DM_MAPIO_DELAY_REQUEUE" statement in multipath_clone_and_map(). I will provide measurement data as soon as I have the time to run more measurements. Bart. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
