High CPU load (D3100 Ubuntu 15.04)

[sanette]

Hi

I have a brand new XPS 13 DE, just installed ubutu 16.04, kernel 4.4.0-24
so I can make some tests.

Indeed there is a problem with CPU. Here is my first test:

* install latest Displaylink driver 1.1.68
* test if it work with my dock D3100 + external HDMI monitor: YES!
* unplug the dock
* reboot (laptop alone, nothing is connected)
* in the terminal, "top" tells me DisplayLinkManager uses between 0% - 0.3%
so this is fine
* close the lid to suspend, re-open to wake up
* now DisplayLinkManager is steadily using 16%CPU !
(with nothing connected) So something is wrong here.

[sanette]

Here is the screenshot
(after resume, with nothing connected to the laptop)

[EDIT] sorry, the image has been shrunk, it's too small.; Anyway this is not important
It's just showing DisplayLinkManager at 16.9% CPU

[Sparxy]

I'm having the same problem. As soon as I plug in a single DisplayLink screen, the DisplayLinkManager CPU usage goes through the roof.

The CPU usage stays this high (around 80-100% of one logical core) as long as I keep using the screen(s).
See screenshot.

Ubuntu 16.04
kernel: 4.4.0-24-generic
DisplayLink 1.1.62

lspci:
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller (rev 06)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller (rev 06)
00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06)
00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06)
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 04)
00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 (rev 04)
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-V (rev 04)
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 (rev d4)
00:1c.6 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #7 (rev d4)
00:1c.7 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #8 (rev d4)
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation HM87 Express LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller (rev 04)
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Mars [Radeon HD 8730M] (rev ff)
01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde/Pitcairn HDMI Audio [Radeon HD 7700/7800 Series] (rev ff)
03:00.0 Network controller: Intel Corporation Wireless 7260 (rev 73)
04:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5227 PCI Express Card Reader (rev 01)

lsusb:
Bus 002 Device 002: ID 8087:8000 Intel Corp.
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:8008 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 003: ID 17e9:ff0b DisplayLink
Bus 004 Device 002: ID 17e9:ff0b DisplayLink
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 004: ID 05c8:0369 Cheng Uei Precision Industry Co., Ltd (Foxlink)
Bus 003 Device 003: ID 154b:005b PNY Flash Drive
Bus 003 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 003 Device 005: ID 8087:07dc Intel Corp.
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Edit: Added zip with output of support tool and other info.

[mlukaszek]

Having DisplayLinkManager process using more CPU with no device connected (what sanette reported) is not normal and we'll be looking into that.

To give context for remaining reports so far: DisplayLinkManager does some heavy lifting to talk to devices and push pixels to all additional screens connected to docking stations - so it will always need some CPU resources to do that.

We use EVDI as a kernel mode DRM driver which receives all notifications from standard Linux subsystems, including those telling there is a change on the screen that needs to be displayed. DisplayLinkManager gets those updates from EVDI, and uses them to refresh screens connected to DisplayLink devices.

The CPU usage is proportional to how much data we need to work with. Generally speaking, the more extra screens, the higher CPU usage.

Unfortunately, some graphical environments (default Unity being a prime example) are working in such a way that the notifications we receive are about an entire screen changing, even if it's not exactly true.

For this reason, we can be forced to refresh all DisplayLink screens even if the update was just for the built-in laptop screen, and there was no real need to update contents of any other screen. We have seen much better behaviour in other desktop environments (e.g. Gnome 3 or KDE), where EVDI is given much more accurate information.

Having full screens needing to redraw will also make the process use more resources than updating a fraction of the screen. Unfortunately, this again comes back to the quality of screen update notifications we receive on Linux - even if the thing changing is tiny, if we're told that we should update the entire screen, we must do as we're instructed.

Having said all that...

We are currently looking at possibilities of reducing the CPU usage on Linux, but first would like understand what CPU usage (and overall performance) are people getting on different setups. Therefore, we'd need your help!

If you see something that you don't like please record a short video (smartphone quality is just fine) and share here. This will let us see how things work on your systems.

Some caveats:
Having Ubuntu's "Display Properties" window opened makes the CPU usage high - as the app is rendering an overlay with a display number on each screen - massively increasing the number of screen updates.

If using Unity desktop environment - for reasons explained above - even having a cursor blinking in console, or "top" window updating itself regularly on the internal screen will cause updates for all DisplayLink screens, too.

Regards,
Michal

[Sparxy]

Hi Michal,

I am using the XFCE desktop environment, which is rather lightweight so I'm not sure whether the amount of CPU usage I'm getting could be considered within normal range. This is why I'm checking in.
This also begs the question whether there's no way for DisplayLink to optimize the drivers to detect which parts of the screen changed more accurately, causing less need for constant screen updates?

Thank you for your help.

[cpo]

Sorry, I gave up on this stuff. I've some work to do currently. No time to experiment with various DisplayLink issues. Fact is that if you work, you'll have some applications open. Browsers with several tabs, multiple terminals, maybe an IDE (intellij in my case), a mail client, chat, etc. I've a 21:9 screen with 2560x1080 pixels on it.

It turned out that the current DisplayLink integration isn't made for my setup. It feels like a proof of concept. Maybe it's ok do simple presentations over it. I don't know why you need a video to understand what ~30fps means. Its just slow. And eats up CPU cycles. And the notebook battery.

Finding applications that may lead to high CPU load because they do things "different" isn't an argument if you need these applications.

That's valid at least for the USB3 connected D3100. I've the Dell USB-C connector, too. But I never got it running with the external screen because of kernel oupses when the HDMI cable is plugged and all screens black.

As a result, I'm running the Notebook without any external screens for three months now. Still having the hope that it will get usable some time.

[Sparxy]

I was able to greatly improve performance by disabling the default XFCE compositor. However, this causes the issue described in http://displaylink.org/forum/showthread.php?t=64586

[lloydwatkin]

Originally Posted by mlukaszek

Unfortunately, some graphical environments (default Unity being a prime example) are working in such a way that the notifications we receive are about an entire screen changing, even if it's not exactly true.

For this reason, we can be forced to refresh all DisplayLink screens even if the update was just for the built-in laptop screen, and there was no real need to update contents of any other screen. We have seen much better behaviour in other desktop environments (e.g. Gnome 3 or KDE), where EVDI is given much more accurate information.

I have installed Gnome 3.20 on Ubuntu 16.04 and am happy to report that CPU usage has dropped dramatically (it was at around 180%). I shall report on stability once I've used it a bit more. Previously my external monitors would freeze regularly with killing the main displaylink process and unplugging the dock the only way to turn them back on.

[asdfwadfawdf]

Originally Posted by mlukaszek

Having DisplayLinkManager process using more CPU with no device connected (what sanette reported) is not normal and we'll be looking into that.

To give context for remaining reports so far: DisplayLinkManager does some heavy lifting to talk to devices and push pixels to all additional screens connected to docking stations - so it will always need some CPU resources to do that.

We use EVDI as a kernel mode DRM driver which receives all notifications from standard Linux subsystems, including those telling there is a change on the screen that needs to be displayed. DisplayLinkManager gets those updates from EVDI, and uses them to refresh screens connected to DisplayLink devices.

The CPU usage is proportional to how much data we need to work with. Generally speaking, the more extra screens, the higher CPU usage.

Unfortunately, some graphical environments (default Unity being a prime example) are working in such a way that the notifications we receive are about an entire screen changing, even if it's not exactly true.

For this reason, we can be forced to refresh all DisplayLink screens even if the update was just for the built-in laptop screen, and there was no real need to update contents of any other screen. We have seen much better behaviour in other desktop environments (e.g. Gnome 3 or KDE), where EVDI is given much more accurate information.

Having full screens needing to redraw will also make the process use more resources than updating a fraction of the screen. Unfortunately, this again comes back to the quality of screen update notifications we receive on Linux - even if the thing changing is tiny, if we're told that we should update the entire screen, we must do as we're instructed.

Having said all that...

We are currently looking at possibilities of reducing the CPU usage on Linux, but first would like understand what CPU usage (and overall performance) are people getting on different setups. Therefore, we'd need your help!

If you see something that you don't like please record a short video (smartphone quality is just fine) and share here. This will let us see how things work on your systems.

Some caveats:
Having Ubuntu's "Display Properties" window opened makes the CPU usage high - as the app is rendering an overlay with a display number on each screen - massively increasing the number of screen updates.

If using Unity desktop environment - for reasons explained above - even having a cursor blinking in console, or "top" window updating itself regularly on the internal screen will cause updates for all DisplayLink screens, too.

Regards,
Michal

I opened Ubuntu bug 1613001
Ubuntu 16.04 LTS, Intel HD Graphics 4000, 1 LVDS laptop display, 1 HDMI, 1 HDMI through DisplayLink USB 3.0.

root 19733 49.1 0.4 2167260 49476 ? Ssl 17:09 127:33 /usr/lib/displaylink/DisplayLinkManager

DisplayLinkManager uses significantly more CPU than everything else and mouse cursor flickers on all displays (LVDS and HDMI) but DisplayLink.

Any workaround so far?

[asdfwadfawdf]

I switched to gnome 3.18 by installing ubuntu-gnome-desktop, cpu utilization barely changed

root 3405 34.7 0.3 2138928 48668 ? Ssl 23:20 7:45 /usr/lib/displaylink/DisplayLinkManager

I don't think switching from Unity to Gnome made any difference. When I browse something like Google Earth on non-displaylink displays, DisplayLinkManager still causes CPU spike