On Thu, 2017-10-12 at 18:01 +0800, Ming Lei wrote: > Even EWMA approach isn't good on SCSI-MQ too, because > some SCSI's .cmd_per_lun is very small, such as 3 on > lpfc and qla2xxx, and one full flush will trigger > BLK_STS_RESOURCE easily. > > So I suggest to use the way of q->queue_depth first, since we > don't get performance degrade report on other devices(!q->queue_depth) > with blk-mq. We can improve this way in the future if we > have better approach. Measurements have shown that even with this patch series applied sequential I/O performance is still below that of the legacy block and SCSI layers. So this patch series is not the final solution. (See also John Garry's e-mail of October 10th - https://lkml.org/lkml/2017/10/10/401). I have been wondering what could be causing that performance difference. Maybe it's because requests can reside for a while in the hctx dispatch queue and hence are unvisible for the scheduler while in the hctx dispatch queue? Should we modify blk_mq_dispatch_rq_list() such that it puts back requests that have not been accepted by .queue_rq() onto the scheduler queue(s) instead of to the hctx dispatch queue? If we would make that change, would it allow us to drop patch "blk-mq-sched: improve dispatching from sw queue"? Bart. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
