[lkml]   [2014]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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:
> 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

 \ /
  Last update: 2014-06-18 06:41    [W:0.071 / U:4.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site