On Thu, 13 Dec 2018 19:59:14 +0100
Paolo Valente <paolo.valente(a)linaro.org> wrote:
> Il giorno 13 dic 2018, alle ore 18:34, stan
> <stanl-fedorauser(a)vfemail.net> ha scritto:
>
> On Thu, 13 Dec 2018 17:46:30 +0100
> Paolo Valente <paolo.valente(a)linaro.org> wrote:
>
>>> Il giorno 13 dic 2018, alle ore 17:41, stan
>>> <stanl-fedorauser(a)vfemail.net> ha scritto:
>>>
>
>> You don't have bfq for a comparison, but you can still get an idea
>> of how good your system is, by comparing these start-up times with
>> how long the same application takes to start when there is no
>> I/O. Just do
>>
>> sudo ./comm_startup_lat.sh <scheduler-you-want-to-test> 0 0 seq 3
>> "replay-startup-io gnometerm"
>>
> cfq with the above command (without I/O): *BIG* difference.
>
Great! (for bfq :) )
> Latency statistics:
> min max avg std_dev conf99%
> 1.34 1.704 1.53367 0.183118 3.66336
> Aggregated throughput:
> min max avg std_dev conf99%
> 0 8.03 5.23143 2.60745 15.4099
> Read throughput:
> min max avg std_dev conf99%
> 0 8.03 5.22571 2.60522 15.3967
> Write throughput:
> min max avg std_dev conf99%
> 0 0.02 0.00571429 0.00786796 0.0464991
>
>> and get ready to be surprised (next surprise when/if you'll try
>> with bfq ...)
>
> I had a response saying that bfq isn't available for single queue
> devices, but there might be a workaround. So it might or might not
> happen, depending on whether I can get it working.
>
Actually, there's still a little confusion on this point. First,
blk-mq *is not* only for multi-queue devices. blk-mq is for any kind
of block device. If you have a fast, single-queue SSD, then
blk-mq is likely to make it go faster. If you have a multi-queue
drive, which implicitly means that your drive is very fast (according
to the current standards for 'fast'), then it is 100% sure that
blk-mq is the only way to utilize a high portion of the max speed of
your multi-queue monster.
To use blk-mq, i.e., to have blk-mq handle your storage, you need
(only) to tell the I/O stack that you want blk-mq to manage the I/O
for the driver of your storage. In this respect, SCSI is for sure the
most used generic storage driver. So, according to the instructions
already provided by others, you can have blk-mq handle your storage
device by, e.g., adding "scsi_mod.use_blk_mq=y" as kernel boot option.
Such a choice of yours is not constrained, in any respect, by the
nature of your drive, be it an SD Card, eMMC, HDD, SSD or whatever
you want. As for multi-queue devices, they are handled by the
NVMe driver, and for that one only blk-mq is available.
Once you have switched to blk-mq for your drive, you will have the set
of I/O schedulers that live in blk-mq. bfq is among these schedulers.
Actually, there is also an out-of-tree bfq available also for the good
old legacy block, but this is another story.
Finally, from 4.21 there will be no legacy block any longer. Only
blk-mq will be available, so only blk-mq I/O schedulers will be
available.
And finally, once I added scsi_mod.use_blk_mq=y to the
kernel command line, I was able to set bfq for my I/O scheduler (for
me, under blk-mq there is only none or bfq). Here are the results of
your utility using bfq. The latency nearly matches no I/O load. Thanks
for writing a utility that is so easy to use, and allows the evaluation
of different schedulers.
bfq
Latency statistics:
min max avg std_dev conf99%
1.51 2.583 1.92533 0.576087 11.5249
Aggregated throughput:
min max avg std_dev conf99%
30.12 142.3 73.5314 45.6032 269.512
Read throughput:
min max avg std_dev conf99%
26.45 136.92 69.5629 44.7932 264.725
Write throughput:
min max avg std_dev conf99%
2.44 5.38 3.96857 0.948603 5.60619
>>> cfq
>>>
>>> Latency statistics:
>>> min max avg std_dev conf99%
>>> 22.142 27.157 24.1967 2.6273 52.5604
>>> Aggregated throughput:
>>> min max avg std_dev conf99%
>>> 67.29 139.74 105.491 19.245 39.7628
>>> Read throughput:
>>> min max avg std_dev conf99%
>>> 51.73 135.67 102.402 21.3985 44.2123
>>> Write throughput:
>>> min max avg std_dev conf99%
>>> 0.01 46.29 3.08857 8.37179 17.2972
>>>
>>> noop
>>>
>>> Latency statistics:
>>> min max avg std_dev conf99%
>>> 40.861 42.021 41.3637 0.595266 11.9086
>>> Aggregated throughput:
>>> min max avg std_dev conf99%
>>> 45.66 72.89 55.9847 5.99054 9.87365
>>> Read throughput:
>>> min max avg std_dev conf99%
>>> 41.69 70.85 51.9495 6.02467 9.9299
>>> Write throughput:
>>> min max avg std_dev conf99%
>>> 0 7.9 4.03527 1.62392 2.67656
And thank you also to all the other contributors to this thread.