Created attachment 86603 [details]
kernel log when CPU usage has increased significantly without apparent cause
linux v3.7.10-1.1-desktop x86_64
nouveau video driver
nVidia gt470 graphics adapter
AMD Athlon II X4 630 Processor
I filed this bug in the Gnome Bugzilla system <https://bugzilla.gnome.org/show_bug.cgi?id=699285>. After a long delay, they suggested filing it here. So here it is.
I have attached a kernel log from today.
Commentary from the Gnome report:
Ever since gnome version 3.2 the mouse movement becomes more uneven as the
logon time increases. Initially the movement is smooth and even as expected. As
the session time increases the movement shows regular pauses (every 1 - 2
seconds) for some fraction of a second, then "catches up" to where it would
have been had it not paused. As the session time increases, so does the
jerkiness, i.e., the pauses increase in length.
This is annoying. It is exaggerated in a VirtualBox VM, guest type os/2, where
tje issue is quite pronounced. Given enough time, though, even native apps show
It is related somehow to the build up of CPU usage. Initially the idle time
usage is about 4% with a browser, email agent and a VM. As time goes by the
idle usage increases to about 15% where the mouse action is so uneven that it
is no longer tolerable.
The problem has worsened with later versions since 3.2; the jerkiness increases
after only several hours rather than days. It has gotten so bad that I have
gone to KDE where there is no such issue.
It occurs for two different mice, a wired unit and a wireless one. I
am currently using a Logitech MX300 mouse. Dis-/re-connecting the mice made no
The only solution so far is to log out and in again, or more recently, use KDE.
Other systems here do not have this problem. The primary difference is that
this system has a nVidia graphics adapter; all the other systems have ATI
adapters of some sort.
See the "top" results below. Note that gnome-shell starts at about 7% CPU
usage, 11 hours later it has risen to 18%. I really prefer Gnome over KDE. It
is sad that this issue has made it unusable.
Here a section of "top" when Gnome first starts after login.
top - 11:55:44 up 11 days, 13:27, 3 users, load average: 4.14, 4.24, 4.30
Tasks: 240 total, 1 running, 238 sleeping, 0 stopped, 1 zombie
%Cpu(s): 2.4 us, 2.6 sy, 0.0 ni, 95.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 8192128 total, 7930368 used, 261760 free, 158984 buffers
KiB Swap: 2104476 total, 80392 used, 2024084 free, 5654784 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14487 jmoe 20 0 2916m 1.0g 982m S 8.0 12.8 5:47.24 VirtualBox
14430 jmoe 20 0 1937m 178m 49m S 7.0 2.2 6:00.63 gnome-shell
14125 root 20 0 342m 93m 25m S 2.3 1.2 3:20.56 Xorg
15310 jmoe 20 0 1878m 248m 45m S 1.7 3.1 6:13.28 thunderbird-bin
16267 jmoe 20 0 340m 17m 12m S 0.7 0.2 0:28.97 gkrellm
14445 jmoe 20 0 1099m 30m 19m S 0.3 0.4 0:06.15 nautilus
18756 root 20 0 0 0 0 S 0.3 0.0 0:01.58 kworker/2:2
19684 root 20 0 0 0 0 S 0.3 0.0 0:01.08 kworker/1:2
21537 jmoe 20 0 19392 1736 1124 R 0.3 0.0 0:00.25 top
1 root 20 0 48376 6428 1588 S 0.0 0.1 0:04.41 systemd
Here a section of "top" after Gnome has run for 11 hours.
top - 23:02:54 up 12 days, 33 min, 6 users, load average: 2.51, 2.56, 2.26
Tasks: 238 total, 1 running, 236 sleeping, 0 stopped, 1 zombie
%Cpu(s): 3.6 us, 9.1 sy, 0.0 ni, 87.0 id, 0.1 wa, 0.0 hi, 0.2 si, 0.0 st
KiB Mem: 8192128 total, 7861724 used, 330404 free, 222484 buffers
KiB Swap: 2104476 total, 84064 used, 2020412 free, 5327096 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14430 jmoe 20 0 1973m 209m 45m S 18.2 2.6 80:11.73 gnome-shell
22624 jmoe 20 0 2926m 1.0g 1.0g S 8.9 13.1 35:06.52 VirtualBox
14125 root 20 0 366m 118m 26m S 3.0 1.5 30:18.57 Xorg
16393 jmoe 20 0 1245m 248m 51m S 1.7 3.1 9:07.27 firefox
24200 jmoe 20 0 1879m 307m 47m S 1.7 3.8 12:00.58 thunderbird-bin
14959 jmoe 20 0 705m 24m 14m S 1.0 0.3 1:15.76 gnome-terminal
16267 jmoe 20 0 340m 17m 12m S 0.7 0.2 6:16.21 gkrellm
23162 jmoe 20 0 19392 1732 1124 R 0.7 0.0 0:00.03 top
Does this still happen with the latest software, i.e. kernel 3.10, mesa 9.2, xf86-video-nouveau 1.0.9? (Kernel 3.11+ apparently has some issues for some NVC1 users, although feel free to try it.)
Also, does this happen on an untainted kernel? (i.e. without virtualbox modules ever being loaded).
Lastly, you can use 'perf' (in tools/perf in the linux-kernel sources) to tell where cpu time is going. Running perf record -g -p $gnome_shell_pid; perf report may be instructive.
>Does this still happen with the latest software, i.e. kernel 3.10,
> mesa 9.2, xf86-video-nouveau 1.0.9?
I do not know. My system is not that up to date. v3.7.10-1.16-desktop x86_64
> Also, does this happen on an untainted kernel?
> Lastly, you can use 'perf' (in tools/perf in the linux-kernel sources) ...
There is no "perf" executable in that directory.
(In reply to comment #2)
> >Does this still happen with the latest software, i.e. kernel 3.10,
> > mesa 9.2, xf86-video-nouveau 1.0.9?
> I do not know. My system is not that up to date. v3.7.10-1.16-desktop x86_64
Perhaps I was unclear. The implication was "update your system to these packages and see if it still happens".
> > Also, does this happen on an untainted kernel?
To be clear, loading the virtualbox modules taints the kernel.
> > Lastly, you can use 'perf' (in tools/perf in the linux-kernel sources) ...
> There is no "perf" executable in that directory.
Yes there is, if you build it. I'm sure there are plenty of wikis about it on the internet if you have trouble getting it to work.
linux v3.11.6-4-desktop x86_64
nouveau video driver 1.0.9
After upgrading to opensuse 13.1 the issue is longer evident.
linux 3.11.10-7-desktop x86_64
Gallium 0.4 on NVC1
This issue has surfaced again in a slightly different form recently, within the last two weeks.
The mouse data stream is interrupted and restarted at random intervals, in generally less than a minute. By "interrupted" I mean that the current mouse state is cleared; if button1 is down, it appears no longer down. And "restarted" means that the mouse state is restored immediately after it is interrupted but it appears as a new state: button1 is now down.
It makes button1 click-drag a chancy process as the stream is sometimes interrupted/restarted quickly enough that it appears as a double-click followed by click-drag.
Still using a kernel "tainted" by VirtualBox.
This new aspect has no obvious affect on CPU usage.
As always, step 1 is "try the latest". That means kernel 3.14.x, mesa 10.1. I'm specifically thinking about commit 7d3428cd4b2ad51af86fdbdf8284ca38fa95e601 in the kernel, which fixed some lag issues for a compton user.
linux 3.16.6-2-desktop x86_64
Gallium 0.4 on NVC1
nVidia geforce gt 730
The mouse movement is not jerky like the original report.
The CPU usage increases quite quickly this time around. The usage value (from TOP) starts at about 2 - 3% for gnome-session, increases to about 15% in 24 hours. I have installed opensuse 13.2 on two other computers that have ATI graphics adapters; they do not exhibit this issue.
If I do not boot every morning, the desktop is likely to freeze by the third day of uptime.
Try the latest software and see if this happens there:
Kernel:stable for a 3.18 kernel
X11:XOrg for the X Stack + Mesa
Report back anyway...
linux 3.16.7-21-desktop x86_64
nvidia GF108 [GeForce GT 730]
The increasing CPU usage is still an issue. Apparently I am the only person to have this problem. :-(
I have been using Xfce; I switched back to Gnome for a while because I prefer it. It was disappointing that this has not been resolved.
It seems to be a nvidia-related (or nouveau?) problem. None of the other linux systems exhibit the CPU usage; the other computers have ATI (built-in or addon) video controllers.
openSUSE Leap 42.1
linux 4.1.12-1-default x86_64
nvidia gt 730
This issue has not been affected by any updates in the last two years. I just updated to updated openSUSE Leap 42.1 which has fairly recent versions of Gnome, etc.
I am deeply disappointed that Gnome's CPU usage proceeded to climb from its initial usage of about 2% to 5% 12 hours later. It follows an identical pattern as originally reported.
Have you tried using 'perf' to determine what's sucking up the CPU?
How do I use perf to monitor Gnome's CPU usage?
(In reply to James Moe from comment #13)
> How do I use perf to monitor Gnome's CPU usage?
Well, presumably it's not "gnome" using CPU, it's some specific process. So then you just do
perf record -g -p pid
(In reply to Ilia Mirkin from comment #14)
> > How do I use perf to monitor Gnome's CPU usage?
> Well, presumably it's not "gnome" using CPU, it's some specific process. So
> then you just do
> perf record -g -p pid
Would I use "perf top" to identify suspect processes? Since I do not know which process is the problem, I cannot provide a PID for the "-p" option.
(In reply to James Moe from comment #15)
> (In reply to Ilia Mirkin from comment #14)
> > > How do I use perf to monitor Gnome's CPU usage?
> > Well, presumably it's not "gnome" using CPU, it's some specific process. So
> > then you just do
> > perf record -g -p pid
> Would I use "perf top" to identify suspect processes? Since I do not know
> which process is the problem, I cannot provide a PID for the "-p" option.
I've never used 'perf top' although it could perhaps be useful here. You could identify the process with 'top'.
Using TOP the most likely suspect is "gnome-shell". How long should I collect data to get a good profile of its usage?
I dunno... a minute or two should be fine. I'm assuming that it's consistently using 5-10% cpu?
Created attachment 119744 [details]
perf data just after starting Gnome
perf ran for about 2 minutes to collect this data. It was run just after starting Gnome.
Unfortunately I can't decode that. It relies on the exact symbols on your machine... could you also run "perf report" and see if anything interesting pops up? Note that the first column with percents tells you how much time is spent in that function and all its descendents, while the second percentage tells you how much time is spent in *just* that function (but not the functions it calls).
Created attachment 119745 [details]
perf data after Gnome had been running about 18 hours
perf data of gnome-shell after 18 hours of uptime. TOP shows that gnome-shell had increased its average CPU usage by a factor of three, from 2.5% to 7%.
Created attachment 119752 [details]
perf data - the initial screenfull of each data set
Great... that points to something in nouveau. But you need debug symbols to make it useful.
Please get debug symbols, and then open up that top 38% node and see what's inside :)
> Please get debug symbols
Which symbol set(s)? I already have the kernel-syms.
Sbcglobal Email Account Support ¶¶+1 855 856 6451¶¶☻ Sbcglobal.Net Email Problem ?1-855-856-6451? Sbcglobal Email Phone Support Number ··1-855-856-6451··
Sbcglobal Email Tech Support Number ```1-855-856-6451```` Sbcglobal.Net Email Support Number ©1-855-856-6451© Sbcglobal Customer Support @18558566451°°°
Sbcglobal Email Customer Service Phone Number @**1-855-856-6451 Sbcglobal Email Toll Free Number(1-855)-856-6451 Sbcglobal Email Technical Contact Number**1-855-856-6451** Sbcglobal.Net Email Customer Support ~1-855-856-6451~
Sbcglobal.Net Email Phone Support ®®18558566451®® Sbcglobal Email Toll Free Number$$$ 18558566451 $$$ Sbcglobal Email Phone Support Number 1-855-856-6451
***1.855.856.6451***sbcglobal.net email customer support @ @ 1-855-856-6451@ @ sbcglobal.net email phone supportSbcglobal Email Toll Free Number$$$ 18558566451 $$$ Sbcglobal Email Phone Support Number 1-855-856-6451 ***1.855.856.6451***sbcglobal.net email customer support USA @ @ 1-855-856-6451@ @ sbcglobal.net email phone supportSbcglobal Email Toll Free Number$$$ 18558566451 $$$ USA Sbcglobal Email Phone Support Number 1-855-856-6451
Was this ever resolved?
(In reply to James Moe from comment #26)
> Was this ever resolved?
No, although someone else came in the other day to #nouveau complaining about high CPU usage when there's tons of output on an xterm. I've seen that behavior myself although I haven't investigated it.
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/59.