On Wed, 12 Jul 2017 23:54:01 +0800 Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> wrote: > On Wed, 12 Jul 2017 14:18:14 +0000 > Bart Van Assche <Bart.VanAssche@xxxxxxx> wrote: > > > On Wed, 2017-07-12 at 09:26 +0100, John Garry wrote: > > > > > What block driver controls the block device for which the performance > > > > > regression > > > > > has been observed? How many hardware queues were created by that block > > > > > driver > > > > > (see also /sys/block/*/mq/...)? > > > > > > Just confirming that we have only 1 queue: > > > /sys/block/sdc/mq/0 as example > > > > Hello John, > > > > Can you also check the I/O scheduler that has been selected? > > > > Thanks, > > > > Bart. > Hi Bart, > > Original numbers were with deadline-mq (not deliberately specified - so the > default for this setup) To flesh them out a bit I've > run the equivalent test with all the options on today's linux next. > > iodepth=2048, 4k blocks read only 6 disks 6 processes. > > SMMU disabled for now due to ongoing work to reduce it's impact. > > none : 716k IOPS > mq-deadline : 305k IOPS > kyber: 321k IOPS > > noop, scsi_mq disable using the kernel commandline option: 937k IOPS > > Thanks, > > Jonathan > Hi Bart, Just wondering if you had any thoughts on how we can proceed with tracking down this regression? I'm not familiar enough with the multiqueue code to really know where to start. If there are any other tests that would be of use, let us know. Thanks for your help on this! Jonathan
