linux-kernel - Re: scsi-mq

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 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:	Tue, 17 Jun 2014 20:44:58 -0700
From:	Jens Axboe <axboe@...nel.dk>
To:	Bart Van Assche <bvanassche@....org>,
	Christoph Hellwig <hch@....de>,
	James Bottomley <James.Bottomley@...senPartnership.com>
CC:	Bart Van Assche <bvanassche@...ionio.com>,
	Robert Elliot <Elliott@...com>, linux-scsi@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: scsi-mq

On 2014-06-17 07:27, Bart Van Assche wrote:
> On 06/12/14 15:48, Christoph Hellwig wrote:
>> Bart and Robert have helped with some very detailed measurements that they
>> might be able to send in reply to this, although these usually involve
>> significantly reworked low level drivers to avoid other bottle necks.
>
> In case someone would like to see the results of the measurements I ran,
> these results can be found here:
> https://docs.google.com/file/d/0B1YQOreL3_FxUXFMSjhmNDBNNTg.
>
> Two important conclusions from the data in that PDF document are as follows:
> - A small but significant performance improvement for the traditional
>    SCSI mid-layer (use_blk_mq=N).
> - A very significant performance improvement for multithreaded
>    workloads with use_blk_mq=Y. As an example, the number of I/O
>    operations per second reported for the random write test increased
>    with 170%. That means 2.7 times the performance
>    of use_blk_mq=N.

Thanks for posting these numbers, Bart. The CPU utilization and IOPS 
speak a very clear message. The only mystery is why the singe threaded 
performance is down. That we need to get sort, but it's not a show 
stopper for inclusion.

If you run the single threaded tests and watch for queue depths, is 
there a difference between blk-mq=y/scsi-mq and the stock kernel?

> I think this means the scsi-mq patches are ready for wider use.

I would agree. James, I haven't seen any comments from you on this yet. 
I've run various bits of scsi-mq testing as well, and no ill effects 
seen. On top of that, Christophs patches are nicely separated and have 
general benefits even for the non-blk-mq cases. Time to shove them into 
the queue for the next merge window?

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/