linux-kernel - Re: [PATCH V6 4/5] blk-mq-sched: improve dispatching from sw queue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 12 Oct 2017 15:33:33 +0000
From:   Bart Van Assche <Bart.VanAssche@....com>
To:     "osandov@...ndov.com" <osandov@...ndov.com>,
        "ming.lei@...hat.com" <ming.lei@...hat.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
        "hch@...radead.org" <hch@...radead.org>,
        "tom81094@...il.com" <tom81094@...il.com>,
        "paolo.valente@...aro.org" <paolo.valente@...aro.org>,
        "snitzer@...hat.com" <snitzer@...hat.com>,
        Bart Van Assche <Bart.VanAssche@....com>,
        "axboe@...com" <axboe@...com>,
        "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "oleksandr@...alenko.name" <oleksandr@...alenko.name>,
        "osandov@...com" <osandov@...com>,
        "loberman@...hat.com" <loberman@...hat.com>,
        "dm-devel@...hat.com" <dm-devel@...hat.com>
Subject: Re: [PATCH V6 4/5] blk-mq-sched: improve dispatching from sw queue

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.