Very slow performance on Debian
ribalda opened this issue · comments
Current version of bmap on combination with the current debian kernel gives a
terrible low performance:
$uname -a
Linux neopili 4.17.0-1-amd64 #1 SMP Debian 4.17.8-1 (2018-07-20) x86_64
GNU/Linux
$sudo bmaptool copy image.wic /dev/sdb
bmaptool: info: discovered bmap file 'image.wic.bmap'
bmaptool: info: block map format version 2.0
bmaptool: info: 248474 blocks of size 4096 (970.6 MiB), mapped 143428 blocks
(560.3 MiB or 57.7%)
bmaptool: info: copying image 'image.wic' to block device '/dev/sdb' using bmap
file 'image.wic.bmap'
bmaptool: WARNING: failed to enable I/O optimization, expect suboptimal speed
(reason: cannot switch to the 'noop' I/O scheduler: [Errno 22] Invalid
argument)
bmaptool: info: 100% copied
bmaptool: info: synchronizing '/dev/sdb'
bmaptool: info: copying time: 1m 57.6s, copying speed 4.8 MiB/sec
If I cat the scheduler file I get the following:
$ cat /sys/dev/block/8:16/queue/scheduler
[mq-deadline] none
The following patch fixes the warning, but not the performance issues:
diff --git a/bmaptools/BmapCopy.py b/bmaptools/BmapCopy.py
index c066828..d17e98b 100644
--- a/bmaptools/BmapCopy.py
+++ b/bmaptools/BmapCopy.py
@@ -715,12 +715,13 @@ class BmapBdevCopy(BmapCopy):
The old settings are saved in order to be able to restore them later.
"""
# Switch to the 'noop' I/O scheduler
try:
with open(self._sysfs_scheduler_path, "r+") as f_scheduler:
contents = f_scheduler.read()
f_scheduler.seek(0)
- f_scheduler.write("noop")
+ f_scheduler.write("none")
except IOError as err:
_log.warning("failed to enable I/O optimization, expect "
"suboptimal speed (reason: cannot switch to the "
Weirdly enugh NOOP ioscheduler is enabled on the kernel config:
$ cat /boot/config-4.17.0-1-amd64 | grep NOOP
CONFIG_IOSCHED_NOOP=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_BRIDGE_IGMP_SNOOPING=y
I have opened a bug at the kernel BTS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906328
After talking to the kernel developers...
https://www.mail-archive.com/linux-block@vger.kernel.org/msg23928.html
The warning is shown because bmap-tools is trying to setup an io sched
that is not available on blk-mq. But that is no excuse to be 5-8 times
slower.
The real culprint was a bug on uas, Fixed with the commit "block:
really disable runtime-pm for blk-mq
that fix is in Debian:
linux-image-4.17.0-3-amd64 4.17.17-1
After installing it. I still get the warning, but the perfomance is comparable to as it
used to be.
According to linux-blq we should not change the io scheduler in blk-mq. So what about downgrading the wardning to log_debug or something similar?
Thanks!
Thans everyone for you help!
Should we fix the tool anyway and be smarter about "noop"? We assume it is always there, but it is not necessarily the case.
I think is just simpler to downgrade the log message to not bother the user.
If noop is not available is because the kernel is using multi queue and then we should not change the io scheduler.
Of course we could read the scheduler file and select among the available... but:
- What do we gain?
- What if the user rmmods the ioscheduler during our read/check/write operation?
Anyway, it is your choice to make, not mine :P
You are the user, I am not using this tool anymore, so it is your choice too :-)
I agree on turning the message to a debug message, would you send a patch?
@dedekind How can't you be using this tool anymore, it is the best thing after caffeine :p Are you using another tool instead or you are just not working on this field anymore?
Thanks!
Just sent a PR
The latter. I just do not need to flash big images anymore. Now I need to use a power meter, so created this one: https://github.com/intel/yoko-tool
:)