After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 665846 - Gnome Shell animations slow down at random point in time with Intel SandyBridge GPU
Gnome Shell animations slow down at random point in time with Intel SandyBrid...
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: general
3.2.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2011-12-09 08:36 UTC by Alessandro Crismani
Modified: 2021-07-05 14:05 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Alessandro Crismani 2011-12-09 08:36:54 UTC
Hi everybody,
I am experiencing a performance downgrade in Gnome Shell over time. More explicitly, after some time using Gnome Shell, the scaling effect "gets corrupted" and slows down. It seems like 
less frames are shown and going to the activity view becomes a quite frustrating 
experience, hurting my concentration.

There isn't a constant slow down, instead at some point the animation instantly performs worse. The "some point maybe 10 minutes after rebooting or hours later. It usually happens if I leave the laptop idle for a long time (say one hour lunch break). Moreover, restarting the shell or logging back doesn't help, I have to reboot to gain smooth animations back.

First, some info:
My laptop is a Lenovo T420s with a Sandy Bridge HD3000 Graphich controller. I've tried many combinations of software to see if something solved it. More 
particularly, I've tried all the possible combinations between (running Arch 
Linux, if that matetrs):

Kernel 3.0.x (where x was the stable minor version at different points in 
time)
Kernel 3.1.rcx
Kernel 3.1.x
Kernel 3.2.rcx

Mesa 7.10.4
Mesa 7.11.0
Mesa from the master tree as of last week (and some other older snapshots).

I've asked on gnome-shell-list and there it was suggested to try standalone mutter, but then I do not know how to see if the performance worsens since there is not an overview. I've tried with perf, but the results I've got with snap or slow animations look quite the same (you can get them at https://dl.dropbox.com/s/nkl5llmht85o81z/fast.data?dl=1 and at https://dl.dropbox.com/s/96qcbbhklb2d1a8/slow.data?dl=1).

I would really appreciate hints on how to debug this, since it kills my Gnome experience, and I lack the knowledge to start looking deeper. If you can give suggestions on which information might be useful I'll gladly provide it. I might record the shell behaviour with a camera for showing what I mean, if it helps!

Lastly, I do not rembember this in the old Gnome 3.0 times, what might have changed?

Cheers,
Alessandro
Comment 1 Mariusz Libera 2011-12-13 15:52:38 UTC
Same thing, over time animations get really slow. 
Alt+F2 r - fixes it for some time.

Sandybridge i3-2310
Fedora 16
Comment 2 Alessandro Crismani 2011-12-14 17:27:21 UTC
Restarting the Shell unfortunately doesn't work for me.

Does anyone have some suggestions on how to get the cause of these slow downs? It seems to me that they might be related to something that happens on idle times, maybe something slows down and doesn't resume back to its original speed. I really have no idea where to look for finding the cause.
Comment 3 Milan Bouchet-Valat 2011-12-16 21:32:39 UTC
Is Xorg eating memory? If you run 'top', you can see whether the RES value gets higher with time. Also, RES might be constant, but Xorg might still eat cache memory, which you can see in the "Swap: ... cached" information.

Anyway, as you both own a Sandybridge card, you'd better report this to the Intel devs at https://bugs.freedesktop.org/enter_bug.cgi?product=xorg (Component "Drivers/intel"). That's certainly not a bug in the Shell itself.
Comment 4 Alessandro Crismani 2011-12-17 12:52:15 UTC
I'll check if Xorg is hogging resources. It still seems quite strange since I have plenty of free RAM, my laptop is equipped with 8 GB.

Furthermore, I've tried installing Fedora on a separate hard drive to check if it was something related to packaging but I get the same behaviour there.

I'll try reporting it to Intel devs after checking for Xorg RAM hogging and trying with a clean user. I'll add a link to the new report when I file it.

Cheers,
Alessandro
Comment 5 Alessandro Crismani 2011-12-21 10:08:36 UTC
Not sure whether Xorg is hogging resources, but I've confirmed that killing it doesn't help when animations slowed down. I have to reboot to get my fast overview back and workspace switching back. I'll report this to Intel devs.
Comment 6 compunix2000 2012-01-12 10:56:39 UTC
I have the same problem on Thinkpad SL510 with Mobile Intel GM45 Express Chipset. But I think it is not a problem with gnome-shell while I have this problem with XFCE (and not with KDE). It becomes slow and with #hdparm -Tt /dev/sda it shows about 50% less "Timing cached reads", meanwhile CPUs work 1% to 3% and iptop command doesn't show any file transfer...
Comment 7 Alessandro Crismani 2012-01-12 11:00:34 UTC
I've reported the bug here
https://bugs.freedesktop.org/show_bug.cgi?id=44006
as suggested before.

Could you please add your information to that report as well?

Currently, my laptop is at Lanovo's repair center, so I can't check your hdparm suggestion, but as soon as it comes back I'll give it a go.
Comment 8 compunix2000 2012-01-15 12:07:49 UTC
Now after many experiments I think it is "Tracker" package that makes the problem. You can disable it and see the result. Tracker is something like Nepomuk in KDE but still in early development stage.
Comment 9 Alessandro Crismani 2012-01-15 13:21:39 UTC
Not sure about it. I only have libtracker installed on my system, not the tracker indexer (and it surely is not running). It might be something different.
Comment 10 compunix2000 2012-01-15 15:33:12 UTC
Which distro do you use? Tracker is default package in gnome 3...
Comment 11 Alessandro Crismani 2012-01-16 08:26:37 UTC
I'm on Arch Linux. I am not sure if tracker is mandatory in Gnome 3, at least not the indexer (maybe some libraries need to be installed, but the indexer is optional, and surely it is optional to run it if you don't need programs depending on it, such as Gnome Documents).

Besides, since this probably isn't a Gnome Shell's bug, could you post some information on the Intel bug report linked in comment 7?
Comment 12 Milan Bouchet-Valat 2012-01-16 09:05:03 UTC
compunix2000, I think you don't experience the same problem at all. It's simply that your computer hangs when doing too much disk I/O. That's something relatively common; I thought a dual-core CPU like yours would be enough to avoid the problem, but... that probably depends on your disk model, etc. Anyways, it's hard to tell because nobody has managed to debug the problem for years. See the Ubuntu report:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/131094

(BTW, Tracker isn't in early development stage, it's been working for years, even if some series were not super stable.)
Comment 13 xgdgsc 2013-05-07 06:51:20 UTC
I experience similar lag on i7 ivybridge. It happens when I open a lot of large programs using a lot of memory (but not CPU or I/O), so it might not be Gnome shell's problem. You might need to consider improving efficiency of the program and the animation under low available memory.
Comment 14 GNOME Infrastructure Team 2021-07-05 14:05:13 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.