Il giorno 16 ott 2018, alle ore 18:14, Federico Motta =

[off-list ref] ha scritto:

=20
On 10/15/18 5:02 PM, Bart Van Assche wrote:

quoted

On Mon, 2018-10-15 at 16:10 +0200, Linus Walleij wrote:

quoted

+ * For blk-mq devices, we default to using:
+ * - "none" for multiqueue devices (nr_hw_queues !=3D 1)
+ * - "bfq", if available, for single queue devices
+ * - "mq-deadline" if "bfq" is not available for single queue =

devices

quoted

quoted

+ * - "none" for single queue devices as well as last resort

=20
For SATA SSDs nr_hw_queues =3D=3D 1 so this patch will also affect =

these SSDs.

quoted

Since this patch is an attempt to improve performance, I'd like to =

see

quoted

measurement data for one or more recent SATA SSDs before a decision =

is

quoted

taken about what to do with this patch.=20
=20
Thanks,
=20
Bart.
=20

=20
Hi,
although these tests should be run for single-queue devices, I tried =

to

run them on an NVMe high-performance device. Imho if results are good
in such a "difficult to deal with" multi-queue device, they should be
good enough also in a "simpler" single-queue storage device..
=20
Testbed specs:
kernel =3D 4.18.0 (from bfq dev branch [1], where bfq already contains
                also the commits that will be available from 4.20)
fs     =3D ext4
drive  =3D ssd samsung 960 pro NVMe m.2 512gb
=20
Device data sheet specs state that under random IO:
* QD  1 thread 1
 * read  =3D 14 kIOPS
 * write =3D 50 kIOPS
* QD 32 thread 4
 * read =3D write =3D 330 kIOPS
=20
What follows is a results summary; under requests I can give all
results. The workload notation (e.g. 5r5w-seq) means:
- num_readers                  (5r)
- num_writers                  (5w)
- sequential_io or random_io   (-seq)
=20
=20
# replayed gnome-terminal startup time (lower is better)
workload  bfq-mq [s]  none [s]  % gain
--------  ----------  --------  ------
10r-seq    0.3725      2.79     86.65
5r5w-seq    0.9725      5.53     82.41
=20
# throughput (higher is better)
workload   bfq-mq [mb/s]  none [mb/s]   % gain
---------  -------------  -----------  -------
10r-rand       394.806      429.735    -8.128
10r-seq       1387.63      1431.81     -3.086
 1r-seq        838.13       798.872     4.914
5r5w-rand      1118.12      1297.46    -13.822
5r5w-seq       1187         1313.8      -9.651
=20

A little unexpectedly for me, throughput loss for random I/O is even
lower than what I have obtained with my nasty SATA SSD (and reported
in my public results).

I didn't expect that little loss with sequential parallel reads.
Probably, when going multiqueue, there are changes I haven't even
thought about (I have never even tested bfq on a multi-queue device).

Thanks,
Paolo

Thanks,
Federico
=20
[1] https://github.com/Algodev-github/bfq-mq/commits/bfq-mq