On 10/12/2017 09:33 AM, Bart Van Assche wrote: > 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"? Yes, it's clear that even with the full series, we're not completely there yet. We are closer, though, and I do want to close that gap up as much as we can. I think everybody will be more motivated and have an easier time getting the last bit of the way there, once we have a good foundation in. It may be the reason that you hint at, if we do see a lot of requeueing or BUSY in the test case. That would prematurely move requests from the schedulers knowledge and into the hctx->dispatch holding area. It'd be useful to have a standard SATA test run and see if we're missing merging in that case (since merging is what it boils down to). If we are, then it's not hctx->dispatch issues. -- Jens Axboe
