Seems that on kernel 4.17 Debian decided to change the default configuration. Maybe we should ping the kernel group?
ricardo@neopili:~/curro/kernel-cleanup$ cat /boot/config-4.17.0-1-amd64 | grep CONFIG_SCSI_MQ_DEFAULT CONFIG_SCSI_MQ_DEFAULT=y ricardo@neopili:~/curro/kernel-cleanup$ cat /boot/config-4.16.0-2-amd64 | grep CONFIG_SCSI_MQ_DEFAULT # CONFIG_SCSI_MQ_DEFAULT is not set >From Kernel sourcee: config SCSI_MQ_DEFAULT bool "SCSI: use blk-mq I/O path by default" depends on SCSI ---help--- This option enables the new blk-mq based I/O path for SCSI devices by default. With the option the scsi_mod.use_blk_mq module/boot option defaults to Y, without it to N, but it can still be overridden either way. If unsure say N. On Fri, Aug 17, 2018 at 12:21 PM Ricardo Ribalda Delgado <[email protected]> wrote: > > Booting 4.17 with the kernel option scsi_mod.use_blk_mq=0 > > returns the write time to the original 25.8 sec > > On Fri, Aug 17, 2018 at 12:15 PM Ricardo Ribalda Delgado > <[email protected]> wrote: > > > > It is a CFast connected via USB3 > > > > Digging a bit, seems to be related to the module option: > > > > scsi_mod.use_blk_mq > > > > which is true on the new kernel and false on the old kernel. > > > > > > On Fri, Aug 17, 2018 at 12:12 PM Simon McVittie <[email protected]> wrote: > > > > > > On Fri, 17 Aug 2018 at 10:27:47 +0200, Ricardo Ribalda Delgado wrote: > > > > Current version of bmap on combination with the current debian kernel > > > > gives a > > > > terrible low performance: > > > ... > > > > $sudo bmaptool copy image.wic /dev/sdb > > > > > > What sort of hardware is /dev/sdb? I think recent kernels offer different > > > classes of scheduler for (rotating, magnetic) hard disks and for > > > solid-state storage, which might explain why you see none instead of noop. > > > > > > If you copy a raw image to the same device on each kernel (without using > > > bmaptool to skip unused blocks), how long does it take with the default > > > scheduler, and how long does it take with the noop or none scheduler > > > (whichever is available)? > > > > > > If there has been a general performance regression in the kernel for > > > this device type, there is unlikely to be anything that bmaptool can do > > > about it, but a refinement of the patch you suggested (checking which > > > schedulers are available, and selecting either noop or none, whichever > > > is available) would make sense. > > > > > > smcv > > > > > > > > -- > > Ricardo Ribalda > > > > -- > Ricardo Ribalda -- Ricardo Ribalda
