Slowdown of X11 drawings in VBox 6.0.10 in comparison to 5.2.* series.

[ci-zephyurus]

First the environment:

Host OS: Windows 10 64bit Guest OS: Debian GNU/Linux 64-bit.

Linux 4.19.0-5-amd64 #1 SMP Debian 4.19.37-6 (2019-07-18) x86_64

Memory: 16 GB memory is assigned to VBox out of 32GB real memory. CPU: Ryzen 2700, 6 out of 16 (8 real core + 8 hyper-thread) are

assigned to the VBox guest.

Real Display used: 3840x2160 (60Hz) Dell Real Display Adaptor on the host: NVidia GeForce GT 1030

Background and Symptom:

I am using VBox under Windows 10 host on a few PC's. I have used VBox for at least several years now.

On a home PC, I switched from 5.2 series to the latest 6.0.10 about a couple of weeks ago, and experienced a visible slowdown of X11 drawing inside the guest Linux. (Say, when I move terminal windows around the screen. The move is not smooth and very jaggy).

Fast operation with VBox 5.2 series

The slowdown is so much so that I switched back to the 5.2.32 VBox today, and verified that the moving of terminal window inside the Linux guest that runs inside 5.2.32 VBox is fast and much smoother. With 6.0.10 VBox, moving windows shows the wiggling of window frame if you know what I mean.

I have duly installed the guest tool in both versions.

BTW, when I downgraded from 6.0.10, I had to reinstall/downgrade VBox extension so that proper USB3.0 support is available. Funny thing is that downgraded VBox 5.2.32 resulted in the fast X11 drawing within the guest OS when I moved the terminal window around EVEN BEFORE I installed the guest tool. (Does the old guest tool remain in the system? I don't think so...)

Observation: High Xorg CPU utilization with VBox 6.0.10

With VBox 6.0.10, the linux command "top" shows the Xorg x11 server consuming almost 20% of CPU time CONSTANTLY. This is definitely the symtom ofslowdown of drawing. The CPU utilization goes up near 25% if heavy drawing is involved: I felt that other operation became also slow from time to time. Xorg was slowing down everything, I think.

OTOH, with VBox 5.2.32, Xorg server in the linux guest OS spends only 2.3% of CPU time when there is not much X11 drawing and the utilization goes up to 5-6% or so when I move the terminal window, etc.. There is a clear difference of drawing efficiency here between the linux guest in Vbox 6.0.10 and 5.2.32.

Display Setting of VBox

Naturally I checked the display setting of the VBox.

Memory for the graphics display is set to 128MB (maximum) in both versions of VBox. (BTW, is this memory size relevant in the days of 4K color display? Or does the guest tool tries to access the native graphics adaptor memory directly???)

With VBox 5.2.32, 2D/3D acceleration is set to 3D acceleration only.

With VBox 6.0.10, there are choices of VGA, ..., SVGA. I checked the both setting of VGA and SVGA and their choice did not make much difference:Still slow drawing in both cases. With 6.0.10., 3D setting does not seem to offer much improvement. I mean disabling (not marking it) does not change much. (I wonder if the guest graphics module is working or not ...)

When I tried to set 2D under 6.0.10, VBox says it is an illegal setting and ignored stating that the virtual machine is set to use video streaming (?) acceleration and it is only supported for Windows guest and thus ignored. (Sorry, I am using a Japanese-locale Windows and and the message shown is in Japanese and the above is my best attempt to translate the gist of the message for this report.)

Well, I can use this 5.2.32 or subsequent 5.2 series until June 2020 when the support of 5.2 series will be terminated.

But I certainly hope to see this issue resolved on this PC before 5.2 series will become unsupported so that I can use 6.0.x series comfortably without X11 drawing slowdown..

Strange thing is that I don't think I see similar slowdown problem on another PC that I use at the office. That machine uses Intel CPU with built-in graphics co-processor and so it does not use separate graphics adaptor. It also runs Windows 10 64-bit and runs Debian GNU/Linux. It runs VBox 6.0.8 or 6.0.10 (I need to re-check.) but the speed of X11 redrawing in the guest linux OS is just fine there. That VBox 6.0 series runs fine on that office PC was the reason I wanted to switch to 6.0 series on my home PC in the first place.

Does anyone see similar X11 slow down inside the linux guest under Windows?

TIA

[Socratis]

Replying to zephyrus:

Does anyone see similar X11 slow down inside the linux guest under Windows?

1. For questions and discussions, you should prefer the forums. It's usually better and faster, if issues get first addressed in the ​VirtualBox forums, a lot more eyes there. More than 95% of the issues are resolved in the forums, which keeps the developers focusing on the bug fixes and enhancements, and there is no need for another ticket to keep track of. For example, yours is most probably not a bug and someone from the developers has to deal with it and close it as "Invalid".

Plus a discussion and analysis on the bug tracker is going to help me, you, and potentially a future drive-by user or two. Not so in the forums, many more tend to benefit...

Open a new thread if you can in the ​Linux Guests section of the forums. Please be sure to mention that you came from the bug tracker and include the ticket number.

2. You were supposed to follow these steps when you filed the bug, and provide a VBox.log:

   Attach a (full) log file ("Machine" menu/"Show Log" in the main VirtualBox Manager window) straight away to save time for you and for us. The log file contains a lot of useful information about both the host and the guest systems as well as information about what happened during a particular machine run. Please do not cut and paste it.

[ci-zephyurus]

Dear Socratis,

Thanks. I will do the following.

I will upload the log file and some X11 graphics performance numbers for the 5.0.32 VBox, and then the log file and X11 graphics performance for the 6.0.10 VBox. (I am doing some computation and benchmarking right now using 5.03.2 VBox. Once I am finished, I will switch to 6.0.10 and obtain the log and performance numbers there.)

THEN, I will post a question to the forum as suggested and mention this ticket's number.

I hope this should get the discussion going with relevant information (hardware/software and the concrete number to compare the slowdown instead of my natural-language description of slowdown.

TIA

[ci-zephyurus]

Log file for VBox 5.0.32 where linux guest X11 server is fast enough.

[ci-zephyurus]

Log file for VBox 6.0.10 where linux guest X11 server is very slow.

[ci-zephyurus]

x11perf benchmark output from within linux inside VBox 5.0.32

[ci-zephyurus]

x11perf benchmark output from within linux inside VBox 6.0.10

[ci-zephyurus]

x11perfcomp: comparison of x11 performance under linux guests inside VBox 6.0.10 and 5.0.32

[ci-zephyurus]

Now I am uploading a few files:

• the VBox log for VBox 5.2.32 and VBox 6.0.10.

I also attach the output of x11perf (x11 benchmarking command) for both X11 in linux guests inside VBox 5.2.32 and VBox 6.0.10.

I additionally attach the comparison of performance figures using the x11perfcomp command. x11perfcomp computes the relative performance of X11 server using the performance figure in the first column (X11 under linux guest inside VBox 6.0.10). The second column is X11 under linux guest inside VBox 5.0.32.

(CAVEAT: When I measured the performance of X11 under linux within VBox 6.0.10, I shrunk the VBox desktop a bit and hide the lower part of VBox window below the lower boundary host Windows 10 desktop. In that configuration of window placement, x11perf under linux guest refused to measure certain performance numbers and so I had to measure a few relevant tests again and add the missing numbers in the x11perf figures for 6.0.10. For those tests not measured by x11perf, the comparison printed by x11perfcomp shows the raw measurement for X11 server under linux inside VBox 6.0.10 as 0 and does not show the relative number.)

As you can see in x11perfcomp-6.0.10-vs-5.0.32.txt, the performance figure for X11 under linux inside VBox 6.0.10 is so bad that the X11 under linux inside VBox 5.0.20 operates up to approximately 480 times faster (!)

E.g.: Simple rectangle drawing. x 263

118.0 31100.0 ( 263.559) 500x500 rectangle

Character Drawing. x 15

90700.0 1390000.0 ( 15.325) Char in 30-char rgb line (Charter 24)

Scroll. x 481

49.2 23700.0 ( 481.707) Scroll 500x500 pixels

Copy. x 487

40.6 19800.0 ( 487.685) Copy 500x500 from window to window

Since operations like character drawing, scroll and copy are basic operations when one uses X11 with terminal emulators, it is definitely the case that X11 under linux inside VBox 5.0.32 feels snappier. Slow scrolling is a pain when I use text editor.

I run xosview command to show the performance of the system graphically. I think that drawing of that simple program resulted in the constant near 20% CPU time usage under linux inside VBox 6.0.10 because it heavily relies on constant copy operation of existing drawing (histogram) to the left as time goes by.

The above figures are with 3D acceleration enabled. In the case of VBox 6.0.10, VBox says it uses VBoxSVGA display adaptor.

Modules are loaded.

One may naturally wonder if the VBox guest modules are properly loaded in linux guest inside VBox 6.0.10. They do.

You can see from the dmesg excerpt below that modules are loaded. Mouse integration and file sharing between the host Windows 10 and linux guest work. So I presume that the vboxvideo is also working despite dismal performance.

Log from dmesg:

From within linux inside VBox 6.0.10 dmesg | grep -i vb [ 0.086970] ACPI: RSDP 0x00000000000E0000 000024 (v02 VBOX ) [ 0.086973] ACPI: XSDT 0x00000000DBFF0040 00004C (v01 VBOX VBOXXSDT 00000001 ASL 00000061) [ 0.086978] ACPI: FACP 0x00000000DBFF0110 0000F4 (v04 VBOX VBOXFACP 00000001 ASL 00000061) [ 0.086982] ACPI: DSDT 0x00000000DBFF0550 0022EA (v02 VBOX VBOXBIOS 00000002 INTL 20100528) [ 0.086988] ACPI: APIC 0x00000000DBFF0280 00007C (v02 VBOX VBOXAPIC 00000001 ASL 00000061) [ 0.086991] ACPI: HPET 0x00000000DBFF0300 000038 (v01 VBOX VBOXHPET 00000001 ASL 00000061) [ 0.086993] ACPI: MCFG 0x00000000DBFF0340 00003C (v01 VBOX VBOXMCFG 00000001 ASL 00000061) [ 0.086995] ACPI: SSDT 0x00000000DBFF0380 0001CC (v01 VBOX VBOXCPUT 00000002 INTL 20100528) [ 1.543405] ata2.00: ATAPI: VBOX CD-ROM, 1.0, max UDMA/133 [ 1.700087] ata1.00: ATA-6: VBOX HARDDISK, 1.0, max UDMA/133 [ 1.701183] scsi 0:0:0:0: Direct-Access ATA VBOX HARDDISK 1.0 PQ: 0 ANSI: 5 [ 1.701821] scsi 1:0:0:0: CD-ROM VBOX CD-ROM 1.0 PQ: 0 ANSI: 5

... other disk images log omitted ...

[ 5.206211] ata16.00: ATA-6: VBOX HARDDISK, 1.0, max UDMA/133 [ 5.206607] scsi 15:0:0:0: Direct-Access ATA VBOX HARDDISK 1.0 PQ: 0 ANSI: 5 [ 9.889597] vboxguest: loading out-of-tree module taints kernel. [ 9.889760] vboxguest: module verification failed: signature and/or required key missing - tainting kernel [ 9.901339] vboxguest: misc device minor 58, IRQ 20, I/O port d020, MMIO at 00000000e8400000 (size 0x400000) [ 9.901340] vboxguest: Successfully loaded version 6.0.10 (interface 0x00010004) [ 10.115181] fbcon: vboxdrmfb (fb0) is primary device [ 10.239548] vboxvideo 0000:00:02.0: fb0: vboxdrmfb frame buffer device [ 10.311567] [drm] Initialized vboxvideo 1.0.0 20130823 for 0000:00:02.0 on minor 0 [ 30.509046] 06:07:25.736995 main VBoxService 6.0.10 r132072 (verbosity: 0) linux.amd64 (Jul 12 2019 11:05:23) release log [ 30.509171] 06:07:25.737168 main Executable: /opt/VBoxGuestAdditions-6.0.10/sbin/VBoxService [ 30.510763] 06:07:25.738741 main vbglR3GuestCtrlDetectPeekGetCancelSupport: Supported (#1) [ 30.553299] vboxsf: g_fHostFeatures=0x8000000f g_fSfFeatures=0x1 g_uSfLastFunction=29 [ 30.553371] vboxsf: Successfully loaded version 6.0.10 [ 30.554288] 06:07:25.782262 automount vbsvcAutomounterMountIt: Successfully mounted 'download' on '/media/sf_download' root@ip030:/media/sf_download#

My suspicion

Any thought or workaround? I am not a VBox developer and can't see any smoking gun from the Log files from VBox 5.0.32 and 6.0.10, but a seasoned developer may catch something there.

I am writing this memo under linux inside VBox 6.0.10, but am reverting to 5.0.32 for comfortable usage now.

I suspect that BITBLT operations are very slow with vbox linux guest tool for 6.0.10, and/or the interfacing with the host graphics adaptor is not working well. But there may be other serious issue. (Maybe all memcopy, memset operations now use slow generic versions instead of CPU-native handcrafted code, etc. due to incorrect compiler flag or something? But I think there is more to this slowdown.)

[ci-zephyurus]

I have posted a comment to the linux guest forum to see if there are similar experiences of slowdown. ​https://forums.virtualbox.org/viewtopic.php?f=3&t=94494

[ci-zephyurus]

This is from a DIFFEREN PC where the X11 server is reasonably fast under linux inside VBox 6.0.10

[ci-zephyurus]

I have uploaded a VBox.log file from a DIFFERENT PC where the X11 server under linux guest inside VBox 6.0.10 is REASONABLY FAST. There, with constant screen update of "xosview" statistics, Xorg server spends only about 1.7-2.0 % of CPU time according to "top" output. The log file is from a running instance and so it does not have the termination portion of the log.

The DIFFERENT PC's environment. Host: Windows 10 64-bit.
Guest : linux: Linux debian-vbox-ci 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) x86_64 GNU/Linux
Memory: 8GB of 16 GB real memory is assigned to VBox 6.0.10 r132072.
CPU: Intel Core i5-8500 CPU.: Out of six cores, two (2) core is assigned to VBox.
Real Display: 3840 x 2160 @ 60Hz PHL 436M6VBR
Display Adaptor: it is built in CPU: Intel (R) UHD Graphics 630

VBox display setting is VBoxVGA and 3d acceleration is checked.

Except for the CPU and the graphics adaptor, I don't think there are other differences.
So I am really puzzled at what makes the X11 server under linux guest inside VBox 6.0.10 on THIS PC run faster than the one on my home PC. Of course the hardware difference (CPU and graphics adaptor) might play a key role. I bet a seasoned developer of VBox guest tool can take a look at VBox log and figure out the cause.

That is my hope.

[/dev/null]

Another 6.0.10 log from a system with the same issue

[/dev/null]

For what it is worth, I have a very similar setup and I am experiencing the same issues.

Host: Win 10 - build 1093
CPU: i7-9750H
GPU: NVIDIA GTX 2060
RAM: 16GB
Display Resolution: 1080p@144Hz

Guest: Debian 10 (amd64)
CPU: 6 (out of 12 cores)
RAM: 8GB (of the 16GB)
Display Resolution: 1080p@60Hz

I've attached my own VBox.log