Skip to contentSkip to conversation

CONFIG_SCSI_MQ_DEFAULT cause slow direct write speed to usb stick

DISCUSSION Andrej Gelenberg 2 participants 3 messages Feb 10, 2015 – Feb 11, 2015 SCSI

lore
Share & tools
lore
#0 lore raw

Hi,

i had found a problem with CONFIG_SCSI_MQ_DEFAULT config option. If it activated, then the write speeds to the /dev/sd* of an usb stick drops
dramatically: it's only about 250 kb/CONFIG_SCSI_MQ_DEFAULTs, but should be about 7 Mb/s. Git bisect also points to commit 24c20f10583647e30afe87b6f6d5e14bc7b1cbc6 'scsi: add a CONFIG_SCSI_MQ_DEFAULT option' (i always set CONFIG_SCSI_MQ_DEFAULT to y, because it sounded interesting). Same problem is also in 3.19 present. Write speeds to a filesystem on that USB-Stick were not so bad, but as i tried to dd in Live-DVD Ubuntu image it was painfully slow. After i disabled CONFIG_SCSI_MQ_DEFAULT write speeds are back to normal.

I created bug report in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=92571

Regards,
Andrej

#1 lore raw
Quoted 14 lines · Andrej Gelenberg

Hi,

i had found a problem with CONFIG_SCSI_MQ_DEFAULT config option. If it activated, then the write speeds to the /dev/sd* of an usb stick drops
dramatically: it's only about 250 kb/CONFIG_SCSI_MQ_DEFAULTs, but should be about 7 Mb/s. Git bisect also points to commit 24c20f10583647e30afe87b6f6d5e14bc7b1cbc6 'scsi: add a CONFIG_SCSI_MQ_DEFAULT option' (i always set CONFIG_SCSI_MQ_DEFAULT to y, because it sounded interesting). Same problem is also in 3.19 present. Write speeds to a filesystem on that USB-Stick were not so bad, but as i tried to dd in Live-DVD Ubuntu image it was painfully slow. After i disabled CONFIG_SCSI_MQ_DEFAULT write speeds are back to normal.

Quoted 2 lines

I created bug report in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=92571

Perhaps a related datapoint: when reading from a uSD card via a USB dongle in lk 3.19 (SCSI_MQ set), blk_get_request() sometimes returns EAGAIN to the sg driver. I'm not sure that I have seen the SG_IO ioctl return EAGAIN via this route before (i.e. before it can even set up the SCSI command). Arguably doing that breaks the long standing interface of ioctl(sg, SG_IO).

Faster storage devices do not seem to have this problem. The laptop involved has plenty of ram and was lightly loaded. This was a synchronous copy of a slow device onto local storage (a SSD) so it is hard to see why there might be a resource problem. By adjusting my user space code (ddpt and sg_dd) to repeat the ioctl, the copy continues normally.

Here is an example:

# ddpt if=/dev/sg1 bs=512 of=x.bin
1953792+0 records in
1953792+0 records out
1281 retries after EAGAIN error(s) during IO
time to transfer data: 59.678788 secs at 16.76 MB/sec

That is not a bad transfer time but other utilities or drivers might dwell longer on those (nuisance) EAGAINs.

Doug Gilbert

#2 lore raw

Hi,

my problem was, that write speed to the device is got really slow from 7 Mb/s to 250 Kb/s, so 16.76 Mb/sec is probably the speed limitation of the uSD Card or is close to that. Do you activated blk-mq for scsi in kernel config or in boot parameters?

Regards,
Andrej

Quoted 10 lines · On Tue, 10 Feb 2015 17:10:18 -0500 Douglas Gilbert <[email protected]>…

Here is an example:

# ddpt if=/dev/sg1 bs=512 of=x.bin
1953792+0 records in
1953792+0 records out
1281 retries after EAGAIN error(s) during IO
time to transfer data: 59.678788 secs at 16.76 MB/sec

That is not a bad transfer time but other utilities or drivers might dwell longer on those (nuisance) EAGAINs.