High CPU usage - slow/lag/skip problem

Zurd zurd33 at gmail.com
Mon Aug 8 02:54:00 UTC 2016


Hi all! I have a problem where Xorg is taking around 30% CPU usage and it
create a slow/lag problem for a fraction of a second about every second.
There's no crash but it's quite annoying. Sometimes a click is not
registered.

It can happen 5 minutes after I boot or after 5 hours. I haven't been able
to know why, it's random. It looks like the same problem as this:
https://lists.freedesktop.org/archives/xorg/2011-September/053299.html

He sums it up quite well by saying:
"I can notice the lag in response time. Video playback also becomes
impossibly slow at this point."

I started a thread on the linux mint forums with a lot of my hardware
information:
https://forums.linuxmint.com/viewtopic.php?f=47&t=226421

Problem started with a new clean install of Linux Mint 18 and I haven't
been able to solve it. So I went back with Linux Mint 17.2 that I had
before and that there was no issue but now the problem is also there. I now
have a good theory on why I have a high cpu usage of Xorg and it's because
of my ultra widescreen monitor. When I installed Linux Mint 17.2, I had a
regular widescreen monitor and Xorg was configured with it. Then I switched
to my new ultra widescreen and everything was well. Until I decided to
completely format and install the new Linux Mint 18.

My monitor is an LG 29UM58-P, resolution is 2560x1080.

So now I'm wondering if the problem is about EDID:
https://wiki.ubuntu.com/X/Troubleshooting/HighCPU
"An example we saw is where a daemon process does polling on X calls, such
as to watch for if a monitor is present. These xrandr calls can be
expensive because they do a probe and analysis of the monitor's firmware.
So as a result the daemon drives X's CPU utilization through the roof (and
causes a bunch of EDID stuff to fill up the Xorg.0.log). The solution in
these cases is to make the daemon stop doing the expensive polling so
frequently (there are cheaper X calls they can use)."

This whole paragraph on EDID/polling/xrandr is quite interesting but
there's no information on how to troubleshoot or solve that problem which
is why I'm posting here. Anyone can shed some lights?

I have a feeling it's about EDID because in my log file
/var/log/Xorg.0.log, I see a bunch of
[   434.373] (--) NVIDIA(GPU-0): LG Electronics LG ULTRAWIDE (DFP-1):
connected
[   434.373] (--) NVIDIA(GPU-0): LG Electronics LG ULTRAWIDE (DFP-1):
Internal TMDS
[   434.373] (--) NVIDIA(GPU-0): LG Electronics LG ULTRAWIDE (DFP-1): 340.0
MHz maximum pixel clock
[   434.373] (--) NVIDIA(GPU-0):
[   434.907] (--) NVIDIA(GPU-0): LG Electronics LG ULTRAWIDE (DFP-1):
connected
[   434.907] (--) NVIDIA(GPU-0): LG Electronics LG ULTRAWIDE (DFP-1):
Internal TMDS
[   434.907] (--) NVIDIA(GPU-0): LG Electronics LG ULTRAWIDE (DFP-1): 340.0
MHz maximum pixel clock
[   434.907] (--) NVIDIA(GPU-0):
[   434.940] (--) NVIDIA(GPU-0): LG Electronics LG ULTRAWIDE (DFP-1):
connected
[   434.940] (--) NVIDIA(GPU-0): LG Electronics LG ULTRAWIDE (DFP-1):
Internal TMDS
[   434.940] (--) NVIDIA(GPU-0): LG Electronics LG ULTRAWIDE (DFP-1): 340.0
MHz maximum pixel clock
[   434.940] (--) NVIDIA(GPU-0):
[   435.474] (--) NVIDIA(GPU-0): LG Electronics LG ULTRAWIDE (DFP-1):
connected
[   435.474] (--) NVIDIA(GPU-0): LG Electronics LG ULTRAWIDE (DFP-1):
Internal TMDS
[   435.474] (--) NVIDIA(GPU-0): LG Electronics LG ULTRAWIDE (DFP-1): 340.0
MHz maximum pixel clock
[   435.474] (--) NVIDIA(GPU-0):

If you look at the timestamp, it happens very very often and it keeps
filling up the log file. After 23 minutes of uptime, the log file
Xorg.0.log is already at 1.5M.

Note that I'm using the latest nvidia driver and that this problem doesn't
happen with nouveau. If I log out and back in again, the problem goes away
but will come back.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg/attachments/20160807/f5af43a4/attachment-0001.html>


More information about the xorg mailing list