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
| ||
|
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/
Powered by blists - more mailing lists