Bug 1731474

1. Please describe the problem:
Since the introduction of blk-mq as the default queuing mechanism for SCSI devices the performance of the SATA HDD on my Dell Inspiring 17 7577 laptop dropped massively. dd reports a max write speed of 10 - 20 MB/s, fdatasync() on files frequently takes ~1 second (looking at strace of normal desktop apps, such as dolphin). OS is installed on an nvme disk and that works fine, but /home is on the HDD and makes the computer almost unusable. Desktop application might become unresponsive at times (in reality they are just writing very slow to the disk, they are working fine). Doing normal work is severely slowed down. Running video games is out of question.

Until recently I was able to switch back to non-MQ and using the CFQ IO scheduler by appending scsi_mod.use_blk_mq=0 and scsi_mod.use_blk_mq=0 to the kernel command line, but now that's not possible any longer, CONFIG_IOSCHED_CFQ is not set in the current fedora kernels and no fallback is possible.

I would imagine this doesn't affect only me and it would be nice if a fallback is offered as it was in the past. Currently the usage of this laptop is prevented by this problem, I cannot run Fedora with a pleasant experience.


2. What is the Version-Release number of the kernel:
kernel-5.1.18-300.fc30 kernel-headers-5.1.18-300.fc30 


3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :

Yes it worked perfectly fine since Fedora 29, when the laptop was purchased. I'm not sure what kernel release introduced the change to default to blk-mq, but that's ok. The problem is there is no fallback any longer. I'm also not sure when CONFIG_IOSCHED_CFQ and co. where removed. The laptop was having thermal issues in the recent months and I stopped using it on a daily basis. I already noticed the problem, but I hoped it was going to be fixed by the time I was going to resolve the thermal issue.


4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:
Yes. I'll attach a block configuration of the computer later. In short it's two VG (one for the nvme and one for the hdd, the hdd one has some space on the nvme as well for optional LVM-cache. Issue happens with and without lvm-cache), with dmcrypt-LUKS encryption for the whole volume groups. File system is XFS on all partitions.

With this setup it should be sufficient to use dd to write to the disk to notice very low write performance, about one order of magnitude lower than expected. strace-ing programs doing small IO can show fdatasync() calls taking very long, up to a full second. I tried a few from the Plasma workspace that looked unresponsive


5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:
Didn't try yet


6. Are you running any modules that not shipped with directly Fedora's kernel?:
Nvidia driver, but I booted without it, no change (main GC is Intel IGP anyway). Nothing else.


7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.

I'll attach kernel logs later