On Thu, 13 Dec 2018 19:59:14 +0100
Paolo Valente <paolo.valente@xxxxxxxxxx> wrote:
> > Il giorno 13 dic 2018, alle ore 18:34, stan
> > <stanl-fedorauser@xxxxxxxxxxx> ha scritto:
> >
> > On Thu, 13 Dec 2018 17:46:30 +0100
> > Paolo Valente <paolo.valente@xxxxxxxxxx> wrote:
> >
> >>> Il giorno 13 dic 2018, alle ore 17:41, stan
> >>> <stanl-fedorauser@xxxxxxxxxxx> 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.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
