GNOME Bugzilla – Bug 665846
Gnome Shell animations slow down at random point in time with Intel SandyBridge GPU
Last modified: 2021-07-05 14:05:13 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
Same thing, over time animations get really slow. Alt+F2 r - fixes it for some time. Sandybridge i3-2310 Fedora 16
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.
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.
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
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.
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...
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.
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.
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.
Which distro do you use? Tracker is default package in gnome 3...
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?
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.)
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.
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.