You are not logged in.
Hello,
I have the following problem for some time now on my Lenovo ThinkPad T550 (Intel Core i5-5300U):
When using Linux kernel 4.18+, I have terrible performance with VirtualBox when it comes to disk I/O.
Kernel version: No issue with kernels up to 4.15. The problem occurs when using any 4.18 or newer kernel. I don't know for 4.16 & 4.17 (they're not maintained for some time now), but I can try them should it be of any help.
VirtualBox versions do not seem to be of any impact. I currently run 6.1.14.
In order to test correctly, I did the following:
Created a VM and installed Ubuntu 20.04 (from mini.iso, only basic system), then waited for the first kernel update;
Downloaded but not installed the updated packages;
Kept the VM in this state (I still do), then cloned it for each of my tests;
* I have both SSD and HDD on the computer, and as I run Arch Linux, I tested with the following configurations:
* Host kernel 5.8 and VM on SSD;
* Host kernel 5.8 and VM on HDD;
* Host kernel 4.14 and VM on SSD;
* Host kernel 4.14 and VM on HDD;
My test was to run `apt upgrade` and measure time between the moment I hit the Enter key and the moment the upgrade process is done and I get the prompt back.
Test results:
5.8 SSD: 9 min
5.8 HDD: 33 min (!!)
4.14 SSD: 2 min 45 sec
4.14 HDD: 3 min 15 sec
As you can see, the figures are quite evoking... This 3-minute operation takes 3 to 11 times the same time with recent kernels.
This forum may not be the right place for this issue (apologies in that case), but I hope some of you can give me hints on how to solve this problem: Do you think as I do that it is about disk I/O? Should I raise this to a kernel mailing list?
Thank you in advance for your time, and for your lights!
Last edited by MasterKTO (2020-09-23 15:08:22)
Offline
This reads like this was probably around the time the scheduler defaults got switched to the MQ set of schedulers. Play with those: https://wiki.archlinux.org/index.php/Improving_performance#Kernel's_I/O_schedulers
Of the available options BFQ is generally mostly in line with the previous default of CFQ.
Offline
Thanks W1del for your quick response.
I have been reading this very instructive wiki page and playing with the available schedulers for the past few days.
First of all, I noticed that the default scheduler used by my 4.14 kernel is Deadline, not CFQ. Regardless, I tried the four solutions available with modern kernels, the multi-queue schedulers.
Whether I use mq-deadline (the default, used for my previous measure), None, BFQ or Kyber, the results are quite similar;
mq-deadline being the best with 9 min for SSD and 33 min for HDD, and None being the worst with 10 min for SSD and 35 min for HDD.
I would then exonerate the schedulers, unless the problem is the use of multi-queue in the first place...
Offline