Thread (52 messages) 52 messages, 8 authors, 2019-06-13

Re: CFQ idling kills I/O performance on ext4 with blkio cgroup controller

From: Srivatsa S. Bhat <hidden>
Date: 2019-05-21 07:19:51
Also in: linux-block, linux-ext4, linux-fsdevel, lkml

On 5/20/19 11:23 PM, Paolo Valente wrote:
quoted
Il giorno 21 mag 2019, alle ore 00:45, Srivatsa S. Bhat [off-list ref] ha scritto:

On 5/20/19 3:19 AM, Paolo Valente wrote:
quoted
quoted
Il giorno 18 mag 2019, alle ore 22:50, Srivatsa S. Bhat [off-list ref] ha scritto:

On 5/18/19 11:39 AM, Paolo Valente wrote:
quoted
I've addressed these issues in my last batch of improvements for BFQ,
which landed in the upcoming 5.2. If you give it a try, and still see
the problem, then I'll be glad to reproduce it, and hopefully fix it
for you.
Hi Paolo,

Thank you for looking into this!

I just tried current mainline at commit 72cf0b07, but unfortunately
didn't see any improvement:

dd if=/dev/zero of=/root/test.img bs=512 count=10000 oflag=dsync

With mq-deadline, I get:

5120000 bytes (5.1 MB, 4.9 MiB) copied, 3.90981 s, 1.3 MB/s

With bfq, I get:
5120000 bytes (5.1 MB, 4.9 MiB) copied, 84.8216 s, 60.4 kB/s
Hi Srivatsa,
thanks for reproducing this on mainline.  I seem to have reproduced a
bonsai-tree version of this issue.  Before digging into the block
trace, I'd like to ask you for some feedback.

First, in my test, the total throughput of the disk happens to be
about 20 times as high as that enjoyed by dd, regardless of the I/O
scheduler.  I guess this massive overhead is normal with dsync, but
I'd like know whether it is about the same on your side.  This will
help me understand whether I'll actually be analyzing about the same
problem as yours.
Do you mean to say the throughput obtained by dd'ing directly to the
block device (bypassing the filesystem)?
No no, I mean simply what follows.

1) in one terminal:
[root@localhost tmp]# dd if=/dev/zero of=/root/test.img bs=512 count=10000 oflag=dsync
10000+0 record dentro
10000+0 record fuori
5120000 bytes (5,1 MB, 4,9 MiB) copied, 14,6892 s, 349 kB/s

2) In a second terminal, while the dd is in progress in the first
terminal:
$ iostat -tmd /dev/sda 3
Linux 5.1.0+ (localhost.localdomain) 	20/05/2019 	_x86_64_	(2 CPU)

...
20/05/2019 11:40:17
Device             tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn
sda            2288,00         0,00         9,77          0         29

20/05/2019 11:40:20
Device             tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn
sda            2325,33         0,00         9,93          0         29

20/05/2019 11:40:23
Device             tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn
sda            2351,33         0,00        10,05          0         30
...

As you can see, the overall throughput (~10 MB/s) is more than 20
times as high as the dd throughput (~350 KB/s).  But the dd is the
only source of I/O.

Do you also see such a huge difference?
Ah, I see what you mean. Yes, I get a huge difference as well:

I/O scheduler    dd throughput    Total throughput (via iostat)
-------------    -------------    -----------------------------

mq-deadline
    or              1.6 MB/s               50 MB/s (30x)
  kyber

   bfq               60 KB/s                1 MB/s (16x)


Regards,
Srivatsa
VMware Photon OS
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help