Xorg High CPU Usage, Sluggish Performance on Fresh Install

English Applications
1

Since a recent reinstall of 12.2 I’ve noticed a constant tendency for Xorg over time to allocate more memory, up to 1g virt, and tie up a core at 80-99% constant usage - which then of course makes the entire system very sluggish to respond. If I logout / login restarting X, everything is fine for a while again.

xorg-x11-server-7.6_1.12.3-1.17.1.x86_64
Nvidia binary driver: 3.10.19
3.4.11-2.16-desktop #1 SMP PREEMPT Wed Sep 26 17:05:00 UTC 2012 (259fc87) x86_64 x86_64 x86_64 GNU/Linux

I’ve applied all Suse updates and updated the Nvidia (binary) driver to the latest version with no result. There does not have to by any other applications running for this to occur - just Kwin and Plasma. No plasma widgets are being used.

I see there are some older issues (11.x days) where this was the case, but not much for recent threads on this.

Any ideas? It’s getting pretty old having such a sluggish system on a fresh install.

# top -p 21740 -n 50
top - 12:01:12 up 4 days, 17:01,  9 users,  load average: 0.23, 0.38, 0.37
Tasks:   1 total,   1 running,   0 sleeping,   0 stopped,   0 zombie
%Cpu(s):  9.8 us,  0.4 sy,  0.0 ni, 89.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:   4046208 total,  3282440 used,   763768 free,      300 buffers
KiB Swap:  4193276 total,    44080 used,  4149196 free,  2524228 cached

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND                                                                                            
21740 root      20   0  339m 248m  37m R  79.2  6.3  79:48.30 Xorg

xrestop output:


xrestop - Display: localhost:0
          Monitoring 42 clients. XErrors: 0
          Pixmaps:   24197K total, Other:    3309K total, All:   27507K total

res-base Wins  GCs Fnts Pxms Misc   Pxm mem  Other   Total   PID Identifier    
2000000    32    2    1  403  611    15586K     16K  15602K 22030 kwin
5200000    37   42    1  370  548     7333K     15K   7349K 30043 Applications - Post New Thread - Mozilla Firefox
2400000    36   36    1   42 138381      305K   3245K   3551K 22049 plasma-desktop
2a00000     6    1    0   74   98      197K      2K    200K 22074 krunner
4c00000     6    5    0   18   17      171K    672B    171K 22288 klipper
4600000     6    6    1   18   31      147K      2K    149K 22200 /home/user : bash
3c00000    15    6    0    8   32       96K      1K     97K 22156 kmix
1000000     5    4    0    4   21       48K    720B     48K 21954 kded4
1600000     4    4    0    4   15       48K    552B     48K 21964 kactivitymanagerd
2800000     2    2    0    4   13       48K    408B     48K 22062 kaccess
1400000     3    3    0    2  555       24K     13K     37K 21959 kglobalaccel
3600000     3    3    0    2   12       24K    432B     24K 22143 akonadi_nepomuk_feeder
4e00000     3    3    0    2   11       24K    408B     24K 30065 kmozillahelper
3a00000     3    3    0    2   11       24K    408B     24K 22142 akonadi_mailfilter_agent
3800000     3    3    0    2   11       24K    408B     24K 22145 nepomukcontroller
3400000     3    3    0    2   11       24K    408B     24K 22141 akonadi_maildispatcher_agent
1800000     3    3    0    2   11       24K    408B     24K 22047 knotify4
1200000     3    3    0    2   11       24K    408B     24K 21962 kwalletd
4a00000     0    1    0    2    8       24K    216B     24K   ?   <unknown>
0000000     2    0    2    0  112        0B      4K      4K   ?   <unknown>
1c00000     4    3    0    1   11        0B    432B    432B 22028 Qt-subapplication
2600000     3    3    0    1   11        0B    408B    408B 22054 kuiserver
4400000     0    1    0    0    5        0B    144B    144B   ?   <unknown>
4200000     0    1    0    0    5        0B    144B    144B   ?   <unknown>
4000000     0    1    0    0    5        0B    144B    144B   ?   <unknown>
3e00000     0    1    0    0    5        0B    144B    144B   ?   <unknown>
3200000     0    1    0    0    5        0B    144B    144B   ?   <unknown>
3000000     0    1    0    0    5        0B    144B    144B   ?   <unknown>
2e00000     0    1    0    0    5        0B    144B    144B   ?   <unknown>
2c00000     0    1    0    0    5        0B    144B    144B   ?   <unknown>
0800000     0    1    0    0    5        0B    144B    144B   ?   <unknown>
5000000     1    1    0    0    0        0B     48B     48B   ?   xrestop
2200000     1    1    0    0    0        0B     48B     48B   ?   <unknown>
1a00000     1    1    0    0    0        0B     48B     48B   ?   <unknown>
2

I have the exact same problem. It was true in 12.1 and I’ve just upgraded to 12.2 a week or so ago and it remains true.

I just installed the absolute latest NVidia driver from their Web site - the one which was just put up last week. For a short while it seemed the issue was gone, but today it’s back again - 50-90% CPU. Only a reboot solves the problem temporarily.

3

Can you shut nepomuk down completely for a while to see if it helps?

openSUSE 12.1 – Taming Akonadi & Nepomuk » TweakHound

And are you using btrfs while don’t have the latest kernel (3.6 series) installed?

For my monitoring sub-forum (Chinese sub-forum), it’s the common reasons for a slow performance…

PS:

Your logs are not enough for us to help debugging.

maybe you need to paste /var/log/messages, /var/log/X11.0.log and /var/log/X11.0.log.old somewhere.

4

Interesting. About 10 days ago, I noticed a slow down on the desktop under a heavy usage scenario and then later, well after the fact, noticed that I actually had used some swap space. That was the first time I’ve used swap in about [mild exaggeration] 200 years [/mild exaggeration].

Since then, I have not observed anything further that might suggest a memory leak occurring. However, I have on a number of occasions seen Xorg eating up about 15% more then what it should be. I have no further ideas on it yet.

(PS - I didn’t see any mention from others about similar circumstances)

5

Ah, yes, fresh install, good point. I’d have to agree that its likely indexing related that you are observing. … why the server though in that regard as opposed to the nepomuk process ??

6

Hi MargueriteSu and Tyler_K,

Thanks for the help. I have disabled nepomuk to see if that helps - should have thought of that, though I also did not see nepomuk indexing processes running when the high XOrg CPU usage was present. I’ve certainly seen this in the past, but it does not appear to be related in this case.

I Just had to restart X again, and the /var/log/Xorg.0.log.old is at SUSE Paste

I am using btrfs with btrfsprogs-0.19-47.1.2.x86_64, kernel is the Suse Desktop version 3.4.11-2.16-desktop #1 SMP PREEMPT Wed Sep 26 17:05:00 UTC 2012 (259fc87) x86_64 x86_64 x86_64 GNU/Linux

I can certainly compile a 3.5.7 or 3.6.7 kernel and test that, it just seemed like this should work with the 3.4.11 Suse kernel. I do not have this issue on my other two systems (Suse 12.1 and 12.2) with kernel 3.4 series on them.

Thanks again.

LewsTherin

7

In my case, I am not running Nepomuk nor btrfs.

I’ve pasted my xorg logs and xorg conf files here:
SUSE Paste

I’ll repeat that the system seems OK after a reboot. At that point xorg will be consuming between 3% and 20% CPU.

After some unspecified time, however, the system will start to be sluggish in terms of window handling in Firefox (file save dialog that pops up when an image file is being saved will go away slowly). A check with top at that point will show xorg going to 50-90% CPU. Swap memory is NOT affected, in fact it hasn’t been touched. Virtual memory is 203m. The longer I run without a reboot, the worse it gets with all applications involving window changes such as Dolphin becoming slower. The system never actually freezes, it just gets progressively more annoying.

8

> I am using btrfs with btrfsprogs-0.19-47.1.2.x86_64, kernel is the Suse Desktop version 3.4.11-2.16-desktop #1 SMP PREEMPT Wed Sep 26 17:05:00 UTC 2012 (259fc87) x86_64 x86_64 x86_64 GNU/Linux

  1. another question to make sure if you’re facing the same situation I faced:

when didn’t you get your btrfs partitions created? and what’s your kernel version (should be < 3.4) at that time?

Kernel 3.4 introduced a new btrfs API which need to rebuild btrfs cache. or you’ll get a very slow startup and runtime performance. That was my case.

  1. According to your X11.0.log, the only error happens here:

(EE) Failed to load /usr/lib64/xorg/modules/libglamoregl.so:  /usr/lib64/xorg/modules/libglamoregl.so: undefined symbol:  _glapi_tls_Context

which may be related to: https://bugzilla.novell.com/show_bug.cgi?id=766513

and it repeatedly reports:





  1.     31.360] (WW) NVIDIA(GPU-0): The EDID for HP w2207 (DFP-1) contradicts itself: mode 
  1.     31.360] (WW) NVIDIA(GPU-0):     "720x480" is specified in the EDID; however, the EDID's 
  1.     31.360] (WW) NVIDIA(GPU-0):     valid HorizSync range (24.000-83.000 kHz) would exclude 
  1.     31.360] (WW) NVIDIA(GPU-0):     this mode's HorizSync (15.7 kHz); ignoring HorizSync check 
  1.     31.360] (WW) NVIDIA(GPU-0):     for mode "720x480". 
  1.     31.360] (WW) NVIDIA(GPU-0): The EDID for HP w2207 (DFP-1) contradicts itself: mode 
  1.     31.360] (WW) NVIDIA(GPU-0):     "720x576" is specified in the EDID; however, the EDID's 
  1.     31.360] (WW) NVIDIA(GPU-0):     valid HorizSync range (24.000-83.000 kHz) would exclude 
  1.     31.360] (WW) NVIDIA(GPU-0):     this mode's HorizSync (15.6 kHz); ignoring HorizSync check 
  1.     31.360] (WW) NVIDIA(GPU-0):     for mode "720x576".

which may be related to:

  1. https://bbs.archlinux.org/viewtopic.php?id=120939
  2. [kubuntu] [SOLVED] Incorrect default monitor resolution [Archive] - Ubuntu Forums](http://ubuntuforums.org/archive/index.php/t-961407.html)

By the way, are you using a dual display card laptop without using bumblebee?

Marguerite

9

You two seem to face a same situation:





  1. [571680.645] (II) LoadModule: "glamoregl"

  1. [571680.645] (II) Loading /usr/lib64/xorg/modules/libglamoregl.so

  1. [571680.663]  (EE) Failed to load /usr/lib64/xorg/modules/libglamoregl.so:  /usr/lib64/xorg/modules/libglamoregl.so: undefined symbol:  _glapi_tls_Context


  1. [571680.663] (II) UnloadModule: "glamoregl"

  1. [571680.663] (II) Unloading glamoregl

  1. [571680.663] (EE) Failed to load module "glamoregl" (loader failed, 7)

so googling “libglamoregl.so: undefined symbol: _glapi_tls_Context” might help.

10

Regarding this error, and further to the suggestions in the Bugzilla thread, check this out:
http://forums.opensuse.org/english/get-technical-help-here/64-bit/479942-right-nvidia-optimus-driver-configuration-2.html#post2506351

Failed with messages: [ERROR]Cannot access secondary GPU - error: [XORG] (EE) Failed to load /usr/lib64/xorg/modules/libglamoregl.so: /usr/lib64/xorg/modules/libglamoregl.so: undefined symbol: _glapi_tls_Context AND [ERROR]Aborting because fallback start is disabled.

Found possible solution on Github Bumblebee Project Forum Issue #262 in post by dliw "]https://github.com/Bumblebee-Project...ee/issues/262]](bumblebee not working · Issue #262 · Bumblebee-Project/Bumblebee · GitHub) (final post in thread, undated, unnumbered) who helpfully advised: “I had the same issue recently and solved this problem by replacing Option “ConnectedMonitor” “DFB” -> Option “ConnectedMonitor” “CRT” in the file “xorg.conf.nvidia”… [ie. -> XorgConfFile=/etc/bumblebee/xorg.conf.nvidia]”

Amended xorg.conf.nvidia as suggested by dliw and this seems to have solved the error described above.

11

With regard to: https://bugzilla.novell.com/show_bug.cgi?id=766513

I’ve read through that and the guy’s problem was never solved because he still got the error message even after everything was shown to be correct with regard to the glamor module. I just went through the list of things he was told to do to verify that the module and the referenced symbol was there - and everything is on my machine. The bug fix they applied is applied to my machine according to the changelog.

As for the suggestion to replace Option “ConnectedMonitor” “DFB” → Option “ConnectedMonitor” “CRT” in the file “xorg.conf.nvidia”… [ie. → XorgConfFile=/etc/bumblebee/xorg.conf.nvidia]", I don’t have an xorg.conf.nvidia file in my /etc/X11 directory. The xorg.conf I posted at the Suse paste link above does not show any “ConnectedMonitor” option. Here it is again:

nvidia-xconfig: X configuration file generated by nvidia-xconfig

nvidia-xconfig: version 310.19 (buildmeister@swio-display-x86-rhel47-08.nvidia.com) Thu Nov 8 02:09:12 PST 2012

Section “ServerLayout”
Identifier “Layout0”
Screen 0 “Screen0”
InputDevice “Keyboard0” “CoreKeyboard”
InputDevice “Mouse0” “CorePointer”
EndSection

Section “Files”
EndSection

Section “InputDevice”
# generated from default
Identifier “Mouse0”
Driver “mouse”
Option “Protocol” “auto”
Option “Device” “/dev/psaux”
Option “Emulate3Buttons” “no”
Option “ZAxisMapping” “4 5”
EndSection

Section “InputDevice”
# generated from default
Identifier “Keyboard0”
Driver “kbd”
EndSection

Section “Monitor”
Identifier “Monitor0”
VendorName “Unknown”
ModelName “Unknown”
HorizSync 28.0 - 33.0
VertRefresh 43.0 - 72.0
Option “DPMS”
EndSection

Section “Device”
Identifier “Device0”
Driver “nvidia”
VendorName “NVIDIA Corporation”
EndSection

Section “Screen”
Identifier “Screen0”
Device “Device0”
Monitor “Monitor0”
DefaultDepth 24
SubSection “Display”
Depth 24
EndSubSection
EndSection

According to some documentation I found, the “ConnectedMonitor” option merely overrides the detected monitor. The options are “DFP” digital flat panel" (anything connected to a DVI port) and “CRT” (anything attached to a 15-pin VGA connector) or “TV”. It is also recommended not to use this option but to use the “UseDisplayDevice” option instead.

Nonetheless, I will try using the ConnectedMonitor option. It makes no sense to me that this would change the ability of Nvidia to detect the glamor module or be unable to report the presence of the missing symbol (which IS present in the module I have loaded) - but I suppose anything is possible. Perhaps Nvidia checks for something with DFP and doesn’t check with CRT so it is able to load the glamor module?

I suspect in reality that there is a further bug in the Nvidia driver or in openSUSE which has not been fixed yet.

I’ll report back if this fix does not work.

There is the suggestion to disable loading this module in the Novell bug report near the bottom. I might try that, too, as I don’t have any Intel graphics in the system, just Nvidia so apparently I don’t need the glamor module, if Stefan Dirsch’s comment at the bottom of the Novell bug report is correct.

Note that all these suggestions do is remove the glamor module as a factor. There’s no guarantee it will fix the high CPU issue at all.

12

Yep. glamor has been turned into a generic 2D acceleration method via OpenGL. Its only useful in a handful of cases. Further, you have to make it an available option in order for it to be used. And just becaues its available as an option, doesn’t mean its actually being used. Even intel (whom developed glamor) don’t use it by default, as the other accel methods are far superior. I’m not certain what it has to do with nvidia – suspect its just a bug in their blob.

As for the suggestion to replace Option “ConnectedMonitor” “DFB” -> Option “ConnectedMonitor” “CRT” in the file “xorg.conf.nvidia”… [ie. -> XorgConfFile=/etc/bumblebee/xorg.conf.nvidia]", I don’t have an xorg.conf.nvidia file in my /etc/X11 directory. The xorg.conf I posted at the Suse paste link above does not show any “ConnectedMonitor” option. Here it is again:
Ah, sorry, I didn’t see it. For that matter, I didn’t even read the referenced bumblebee thread – just saw the post here this morning and thought that it might be a quick fix for you guys for that particular issue (* more on this in a moment). And come to think of it, its not clear what the person is reporting success with – did changing the connected monitor option resolve the reported glamor error or just the inability to access the second gpu??

According to some documentation I found, the “ConnectedMonitor” option … It makes no sense to me that this would change the ability of Nvidia to detect the glamor module or be unable to report the presence of the missing symbol (which IS present in the module I have loaded)
indeed

  • but I suppose anything is possible…Perhaps Nvidia checks for something with DFP and doesn’t check with CRT so it is able to load the glamor module?
    Indeed, who knows but them

Nonetheless, I will try using the ConnectedMonitor option.
Its pretty harmless, so worth the long shot that it helps with that error

I suspect in reality that there is a further bug in the Nvidia driver or in openSUSE which has not been fixed yet.
Agreed, especially as it pertains to the former

Note that all these suggestions do is remove the glamor module as a factor. There’s no guarantee it will fix the high CPU issue at all.
Agreed, there is a good chance that its just a rather benign secondary issue. (* with this being my linking point to my above comments of “particular issue” and “more on this in a moment”)

13

Well, I can testify that neither changing the ConnectedMonitor to “CRT” nor commenting out the lines in the 50-glamor.conf file works.

In fact, the system won’t boot with those changes.

I changed both items at the same time. The system wouldn’t boot.

I removed the ConnectedMonitor option. System still wouldn’t boot.

I then edited the 50-glamor file to only comment out loading the glamor module, not the other one. System still wouldn’t boot.

Removed the comment from the glamor module. System boots again.

So much for the advice Stefan Dirsch gave:
(In reply to comment #24) > Should i disable glamor in /etc/X11/xorg.conf.d/05-glamor.conf? > And if yes, how? If you like, you can comment out the lines in this file to disable the load of the “glamoregl” module. Otherwise just ignore this error message.

Well, that does NOT work. It hoses your system.

What I haven’t done is just inserting the ConnectedMonitor option to “CRT” without messing with the 50-glamor file. I’ll try that next, but my guess is it won’t change anything.

14

Well, I set the “ConnectedMonitor” to “DFP” - that killed the monitor! When it loaded X, the monitor went dark!

So I removed that and changed it to “ConnectedMonitor” “CRT”. The monitor - which note IS a flat panel ASUS connected to a DVI port, NOT a “CRT” - came up and the system booted. Examining the xorg.0.log file showed absolutely no change to the glam module error message.

So I changed the “ConnectedMonitor” option to the “UseDisplayDevice” option with “DFP” and that works. No change in the glam module error message.

So I changed the “UseDisplayDevice” option to say “CRT”. No change.

Which leads me to believe that the Nvidia drivers are ignoring those options completely, except for “ConnectedMonitor” which kills the monitor.

So we have one hundred percent failure to deal with the glamor module issue and therefore also no solution to the high CPU issue.

Anyone got any other ideas?

15

On 2012-11-26 22:16, richardstevenhack wrote:

> Anyone got any other ideas?

Do you have flash animations running in FF?

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” (Minas Tirith))

16

Nope. I’m talking doing a Google Image Search for some hot babes and downloading images. That’s it, besides normal Web surfing to my usual sites, none of which are Flash heavy. I have AdBlock and NoScript running to block the usual garbage.

I don’t just notice the slowness in Firefox, although that is where I see it first because I spend a lot of time surfing and doing page and image downloads. Once the slowness is there, just doing an Alt-Tab back and forth between open windows or doing something in Dolphin will jack Xorg up to 50-90%.

17

On 2012-11-27 02:16, richardstevenhack wrote:

> I don’t just notice the slowness in Firefox, although that is where I
> see it first because I spend a lot of time surfing and doing page and
> image downloads. Once the slowness is there, just doing an Alt-Tab back
> and forth between open windows or doing something in Dolphin will jack
> Xorg up to 50-90%.

If closing FF when it happens helps, then that’s it.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” (Minas Tirith))

18

In my case FF makes no difference. The high CPU usage occurs after a reboot in which FF is never run, so it is dependent on the browser, flash, etc.

In fact, you can just reboot - launch no applications whatsoever (other than plasma-desktop, kmix and hp-systray) - come back a while later and Xorg is at 90%+.

Even if you kill kmix, hp-systray, etc. - same thing.

This was actually happening in 12.1 as well - that’s why I decided to do a fresh install of 12.2. I had thought it might be btrfs changes or perhaps an issue with the 4k sector drive.

Reinstalled 12.2 onto a different drive just to rule out any 4k issues, fresh install of 12.2, full format - no old file systems.

Xorg still goes nuts.

Perhaps something introduced in the Nvidia driver at some point? I might try an older Nvidia driver, or nouveau driver, though I’d prefer the Nvidia driver (for CUDA).

Out of two OpenSuse 12.2 and one 12.1 machines I use daily (work, home, notebook) this is the only system I’ve seen this on - and the only one which is Nvidia - the others are ATI and Intel, which is interesting.

LewsTherin

19

On 2012-11-28 03:06, LewsTherinTelemon wrote:
> robin_listas;2506807 Wrote:

> In my case FF makes no difference. The high CPU usage occurs after a
> reboot in which FF is never run, so it is dependent on the browser,
> flash, etc.
>
> In fact, you can just reboot - launch no applications whatsoever (other
> than plasma-desktop, kmix and hp-systray) - come back a while later and
> Xorg is at 90%+.

Oh :frowning:

> Even if you kill kmix, hp-systray, etc. - same thing.
>
> This was actually happening in 12.1 as well - that’s why I decided to
> do a fresh install of 12.2. I had thought it might be btrfs changes or
> perhaps an issue with the 4k sector drive.

If you have the space, try a secondary installation with ext4 only :-?

> Reinstalled 12.2 onto a different drive just to rule out any 4k issues,
> fresh install of 12.2, full format - no old file systems.
>
> Xorg still goes nuts.

:frowning:

> Perhaps something introduced in the Nvidia driver at some point? I
> might try an older Nvidia driver, or nv driver, though I’d prefer the
> Nvidia driver (for CUDA). Out of 2 OpenSuse 12.2 and one 12.1 machine
> that I use daily, this is the only system I’ve seen this on - and the
> only one which is Nvidia - the others are ATI and Intel, which is
> interesting.

Does your system work with the nouveau opensource driver? Or other video
card (even nvidia, but different model)?

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

20

Interestingly, I switched to the nouveau driver. System ran all night, with FF open with a few sites (no flash) and for the first time ever Xorg was not at 90% this morning. It was completely responsive, like it should be.

I’ll run it another day or two and put more load on it, then switch back to nvidia driver, etc. to verify this - but it is certainly looking like it.

Cheers,
LewsTherin