Bug 69827 - [NVC1] Uneven, jerky mouse movement, increasing CPU usage
Summary: [NVC1] Uneven, jerky mouse movement, increasing CPU usage
Status: UNCONFIRMED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: 7.7 (2012.06)
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL: https://www.wikigenes.org/e/author/e/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-26 01:56 UTC by James Moe
Modified: 2017-12-31 12:46 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
kernel log when CPU usage has increased significantly without apparent cause (92.31 KB, text/plain)
2013-09-26 01:56 UTC, James Moe
no flags Details
perf data just after starting Gnome (4.57 MB, application/octet-stream)
2015-11-17 17:10 UTC, James Moe
no flags Details
perf data after Gnome had been running about 18 hours (4.17 MB, application/octet-stream)
2015-11-17 17:17 UTC, James Moe
no flags Details
perf data - the initial screenfull of each data set (6.70 KB, text/plain)
2015-11-17 23:21 UTC, James Moe
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description James Moe 2013-09-26 01:56:25 UTC
Created attachment 86603 [details]
kernel log when CPU usage has increased significantly without apparent cause

openSUSE v12.3
  linux v3.7.10-1.1-desktop x86_64
  gnome 3.6.2
  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
the jerkiness.

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
difference.

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
Comment 1 Ilia Mirkin 2013-09-26 23:54:12 UTC
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.
Comment 2 James Moe 2013-10-06 05:32:14 UTC
>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?
>
Yes.

> Lastly, you can use 'perf' (in tools/perf in the linux-kernel sources) ...
>
There is no "perf" executable in that directory.
Comment 3 Ilia Mirkin 2013-10-06 05:35:51 UTC
(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?
> >
> Yes.

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.
Comment 4 James Moe 2013-11-26 05:48:33 UTC
opensuse v13.1
  linux v3.11.6-4-desktop x86_64
  gnome 3.10.1
  nouveau video driver 1.0.9

After upgrading to opensuse 13.1 the issue is longer evident.
Comment 5 James Moe 2014-05-01 00:58:21 UTC
linux 3.11.10-7-desktop x86_64
gnome 3.10.2
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.
Comment 6 James Moe 2014-05-01 06:10:04 UTC
linux 3.11.10-7-desktop x86_64
gnome 3.10.2
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.
Comment 7 Ilia Mirkin 2014-05-01 06:21:44 UTC
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.
Comment 8 James Moe 2014-12-15 19:37:30 UTC
openSuse 13.2
linux 3.16.6-2-desktop x86_64
Gnome 3.14.1
Gallium 0.4 on NVC1
nVidia geforce gt 730

It's baaaack.

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.
Comment 9 Tobias Klausmann 2014-12-15 20:04:08 UTC
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...
Comment 10 James Moe 2015-08-03 19:24:13 UTC
opensuse 13.2
linux 3.16.7-21-desktop x86_64
nvidia GF108 [GeForce GT 730]
gnome 3.14.5
xf86-video-nouveau 1.0.11

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.
Comment 11 James Moe 2015-11-16 17:54:15 UTC
openSUSE Leap 42.1
linux 4.1.12-1-default x86_64
Gnome 3.16.2
nouveau 2.4.65
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.
Comment 12 Ilia Mirkin 2015-11-16 19:01:27 UTC
Have you tried using 'perf' to determine what's sucking up the CPU?
Comment 13 James Moe 2015-11-16 22:44:47 UTC
How do I use perf to monitor Gnome's CPU usage?
Comment 14 Ilia Mirkin 2015-11-16 22:46:08 UTC
(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
Comment 15 James Moe 2015-11-16 22:57:12 UTC
(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.
Comment 16 Ilia Mirkin 2015-11-16 22:59:11 UTC
(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'.
Comment 17 James Moe 2015-11-16 23:18:54 UTC
Using TOP the most likely suspect is "gnome-shell". How long should I collect data to get a good profile of its usage?
Comment 18 Ilia Mirkin 2015-11-16 23:19:25 UTC
I dunno... a minute or two should be fine. I'm assuming that it's consistently using 5-10% cpu?
Comment 19 James Moe 2015-11-17 17:10:46 UTC
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.
Comment 20 Ilia Mirkin 2015-11-17 17:17:05 UTC
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).
Comment 21 James Moe 2015-11-17 17:17:36 UTC
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%.
Comment 22 James Moe 2015-11-17 23:21:14 UTC
Created attachment 119752 [details]
perf data - the initial screenfull of each data set
Comment 23 Ilia Mirkin 2015-11-17 23:23:35 UTC
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 :)
Comment 24 James Moe 2015-11-18 21:03:37 UTC
> Please get debug symbols
>
Which symbol set(s)? I already have the kernel-syms.
Comment 25 Sbcglobal.Net Email Phone Support 18558566451 2017-06-30 10:36:58 UTC
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
Comment 26 James Moe 2017-11-01 20:14:23 UTC
Was this ever resolved?
Comment 27 Ilia Mirkin 2017-11-01 20:45:39 UTC
(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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.