Go Back   DisplayLink Forum > DisplayLink Graphics Technology > Linux and Open Source

Reply
 
Thread Tools Search this Thread Display Modes
Old 10-01-2020, 09:39 AM   #1
Jan Hubený
Junior Member
 
Join Date: Oct 2020
Posts: 4
Default dIsplayLinkManager high CPU load

Hello,

I have fresh installation of Ubuntu 20.04 LTS oin Dell Vostro 5590 with integrated Intel UHD graphics and dedicated Nvidia GP108M [GeForce MX250]. I use the Dell D6000 universal docking station.

In order to have the display link working correctly with integrated graphic card I follow the post

https://www.displaylink.org/forum/sh...ad.php?t=67148

The display link is now working, however the displayLinkManager process generates huge CPU load after each event (mouse move, change of the displayed content after key press, change of the displayed content by program - htop, video player, etc). The high CPU load is noticeable on all 8 threads.

I suppose, that this is not normal. Exists there some workaround?

Thank you,

Jan Hubeny
Attached Files
File Type: zip DLSupportTool_Output_2020-10-01T10:36:56.919848.zip (789.3 KB, 0 views)
Jan Hubený is offline   Reply With Quote
Old 10-01-2020, 04:57 PM   #2
MaxAsdoria
Junior Member
 
Join Date: Oct 2020
Posts: 1
Default

Hello !

I've the same problem with a Dell Vosto 15 3000 ( And 2 screens) .

CPU going at 50-70% when i do something.

Thanks for help
MaxAsdoria is offline   Reply With Quote
Old 10-08-2020, 01:06 PM   #3
dampel
Junior Member
 
Join Date: Sep 2020
Posts: 3
Default

Hi,
You can try steps from this post:
https://displaylink.org/forum/showthread.php?t=67344
But if you have possibility change you docking station to that witch not require DisplayLink.

I'm looking for such docking station.

Best Regards
dampel
dampel is offline   Reply With Quote
Old 10-12-2020, 02:31 PM   #4
mauromol
Junior Member
 
Join Date: Mar 2015
Posts: 8
Default

Same problem here with Kubuntu 20.04. Monitoring this thread in case anyone from DisplayLink posts something.
mauromol is offline   Reply With Quote
Old 10-13-2020, 05:44 PM   #5
devnull10
Junior Member
 
Join Date: Oct 2020
Posts: 6
Default

Also have this problem, Ubuntu 20.04 on a Lenovo laptop, AMD Raedon Graphics card. Installed the latest version of the driver, however when I plug in the displaylink the DisplayLinkManager process immediately starts eating up CPU. If I drag anything onto the other screen it jumps to well over 100% and starts really stuttering. Seems like a very common issue based on the number of posts I've seen, but unfortunately no resolution!
devnull10 is offline   Reply With Quote
Old 10-14-2020, 12:36 PM   #6
fitter
Junior Member
 
Join Date: Jul 2020
Posts: 8
Default

Actually I do not remember if I checked the CPU usage, but that might be the source why the screen was very laggy and audio choppy. I have system with AMD CPU+GPU and Ubuntu 20.04

Idk whats the status of this project, but I need to admit that since the release of 20.04 the DisplayLink team is not very audible on this forum. Recently there were no replies from them at all.
So well, lets hope a new kernel 5.8 will bring the fix for our issues and this project will not become an abandonware
fitter is offline   Reply With Quote
Old 08-13-2021, 05:47 PM   #7
mauromol
Junior Member
 
Join Date: Mar 2015
Posts: 8
Default

I'm now using DisplayLink driver 5.4 under Kubuntu 20.04 and ensured to use a USB 3.0 port of my notebook rather than a 2.0 one (... oh well, I just recently discovered that the ports I was using were not 3.0 ones but rather 2.0...).

The DisplayLink now works decently, however the CPU consumption is always relatively high (a constant ~10% at minimum, with peaks at 25% on a 4-core CPU, that means a whole core).
However it rarely happens that an application starts to make the DisplayLinkManager process crazy, so that it starts to eat a whole CPU core constantly...
In these cases, it's usually enough to minimize that application window or restart it. The problem is that it may be hard to identify which is the actually affected application...

I don't know whether the high CPU usage of DisplayLinkManager is a technical limit of how the video over USB passthrough is implemented, however I read a lot of posts on the Internet which say that under Windows there's no such CPU usage problem, so perhaps we can still hope for improvements under Linux as well?
mauromol is offline   Reply With Quote
Old 08-28-2021, 08:27 AM   #8
Christian Groove
Junior Member
 
Join Date: Aug 2017
Location: Bavaria-Germany
Posts: 6
Default Overall bad display link driver design

I started to use DisplayLink solutions in 2017. I was using a quite old notebook and was happy to attache one 4k or two 2QWD displays. Anyway, the permanent CPU load of at least 10% (up to 100 and more) surprised me.

How can a DMA (i expected this) may cause a such a high an also altering CPU load, and why does a Windows session does not show a similar ressource consumption, strange ... yes! I assumed (and still do) that the display-link driver is copiing a section from the video ram and sends it over the USB link to the attached docking station into its video ram. A took a look into evdi code and i felt validated.

So in this case, there is no reason for the CPU consumption. A dma does not cost any cpu time, that is the reason why DMA exists. So what went wrong?

Lets jump into 2021, i purchades a modern Lenovo 16p2 with USB-C 3.1 gen2 ports with a 10Gb/s sockets. Great on Windows-10 there are 3 4K Monitors running between 30hz-60Hz and this is fine, cause i am a developer and not a gamer. I can live with the bugs in W10 (loosing refresh for some Windows, but this may be an ati-driver problem) and some crashes (hey thats W10),

Trying Linux (Fedora or Ubuntu) ends up in a desaster. Surprisingly there a 2 monitors only available (of 3) and the Wayland support is getting better while X11 is completly unusable (not interaction possible). Some strange thing are enlisted:

- each of the monitors are showing a mouse cursor
- on Wayland high cpu load (>150%) on the displaylink process
- strace'ing that process shows, that the process does not leave a select call, while the process is running at 100% and more. So the ressource consumption happends inside the system-side and not the user space. So the driver is broken (similar to 2017)
- some DMA related messages on my lenovo 16p2 similar to those (see [ 272.075587] evdi evdi.0: cannot be used for peer-to-peer DMA as it is not a PCI device). Is there a problem with the USB-DMA implementation on AMD devices?

Maybe somebody has answers to my questions:
- Is there somebody out the, who created a kernel-log that gives an hint, where the cpu-ressources are burned in the kernel/driver?
- how to i check the status of the attached USB devices (especially how fast they a working: using lsub or some hints in the proc-file system) ?

Last edited by Christian Groove; 08-28-2021 at 08:36 AM.
Christian Groove is offline   Reply With Quote
Old 09-02-2021, 08:54 AM   #9
ezekiel
Junior Member
 
Join Date: Sep 2021
Posts: 1
Default

Just registered to confirm that the DisplayLink linux driver is a hot mess that is close to unusable. CPU load exceeds 100% whenever anything happens on a display. There seems to be no solution available. The issue has been around for years, with no fix, reaction or comment from Displaylink. So much for Linux support.
ezekiel is offline   Reply With Quote
Old 09-02-2021, 11:47 AM   #10
perceval
Junior Member
 
Join Date: Sep 2021
Posts: 2
Default problem confirmation

The same here, I just registered to indicate that I have the same performances issues on my AMD latptop on Ubuntu 20.04.

The screen is really laggy I can't work this way.
perceval is offline   Reply With Quote
Reply

Tags
high cpu load, intel, nvidia, ubuntu 20.04

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 06:17 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.