dIsplayLinkManager high CPU load

[Christian Groove]

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) ?