I have started seeing (presumably) the same problem after rebooting my updated f17 system.

Downgrading (ie removing everything from -testing) didn't make the problem go away.

I have not been able to reproduce the system on another machine.

Honestly, I wasn't expecting the strace to show anything useful - it generally doesn't for a GUI program, but there's actually a smoking gun in it:

inotify_add_watch(19, "/home/anthony/.config/menus/gnomecc-merged", IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR) = -1 ENOENT (No such file or directory)
inotify_add_watch(19, "/etc/xdg/menus/gnomecc-merged", IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR) = -1 ENOENT (No such file or directory)
inotify_add_watch(19, "/home/anthony/.config/menus/applications-gnome-merged", IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR) = -1 ENOENT (No such file or directory)
inotify_add_watch(19, "/etc/xdg/menus/applications-gnome-merged", IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR) = -1 ENOENT (No such file or directory)

Occurs three times during the trace, presumably over a short period of time. So, for some reason, it's constantly re-adding file-changed monitors for menu files.

As a first test, can you move .config/menus/ away to a different location and see if that makes a difference to the problem?

Created attachment 579580 [details]
gnome shell strace

It seems like moving .config/menus away made the problem even worse for me. Before it rarely went over 100% - now it do that most of the time.

I have for example /proc/1826/fd/19 -> anon_inode:inotify and strace see for example almost 2000 continues lines like
16:21:08 read(19, "\25\0\0\0\2\0\0\0\0\0\0\0\20\0\0\0l\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 1024) = 32
followed by a similar number of
16:21:08 gettimeofday({1335190868, 881922}, NULL) = 0

I don't know if that is what is eating cpu, but it seems suspicious.

Updating pam.d with systemd stuff as describe do Bug 815413 seems to have done that I no longer see the problem.

That will however at most be a trigger; it is still be a bug in gnome-shell that wrong permissions can cause something to spin this way.

I'm seeing the same 100% (actually 222%) gnome-shell cpu usage and inotify calls in strace. I tried following Mads suggestion with authconfig but couldn't get it to reduce (was there a X restart in the middle ? just doing gnome-shell restarts via alt-F2+lg+r didn't work).

Will be happy to provide any further information.

$ rpm -q gnome-shell
gnome-shell-3.4.1-4.fc17.x86_64


Alon

if you mkdir -p the directories that it says "No such file or directory" for does it settle down?

Kind of reminds me of https://bugzilla.gnome.org/show_bug.cgi?id=476938 (though we don't use gamin anymore)

(In reply to comment #5)
> I tried following Mads suggestion with authconfig but
> couldn't get it to reduce (was there a X restart in the middle ? just doing
> gnome-shell restarts via alt-F2+lg+r didn't work).

Yes, at least that. I would do a reboot after changing the pam config to make sure all components pick up the right and consistent configuration.

I'm also having this problem. Installed Fedora 16 as a virtual machine inside Virtualbox on a Windows 7 host a few days ago and upgraded to Fedora 17 today using preupgrade. The fixes in Bug 815413 didn't fix my issues, and I am fully up to date in yum with the patch to pam that was produced from that bugfix.

(In reply to comment #6)
> if you mkdir -p the directories that it says "No such file or directory" for
> does it settle down?
> 


That results in
1) no more inotify calls
2) still large cpu usage, about the same. (it ranges 30%-120%)

Attaching strace.

> Kind of reminds me of https://bugzilla.gnome.org/show_bug.cgi?id=476938
> (though we don't use gamin anymore)

Doesn't look like the only problem since creating the directories didn't drop the cpu load.

Created attachment 589776 [details]
strace after mkdir -p for inotify

gnome-shell strace (on the first process that shows up with pgrep gnome-shell) that shows a lot of activity, after creating the missing directories for successfull inotify calls - two in /etc and two in $HOME/.config

I take it back, I rebooted and now I have no problems with gnome-shell, meaning cpu usage went down to normal, it's responsive as expected. Unfortunately I don't know what solved the problem :/ Just FYI restarting gnome-shell was not enough - i.e. running it under a separate "dbus-launch gnome-shell" while the previous session was still alive.

Grub still has an entry for 3.3.7-1.fc16.x86_64 for me, where gnome-shell runs at about 30-40% CPU. Unsure if that helps anybody.

I've ran mkdir -p as suggested on those 4 directories (although I never saw that error pop up in my strace of gnome-shell), no difference.

Unsure how to attach files here, so here's parts of a strace I did: http://p.sldr.us/raw/NEAsvoTl/ http://p.sldr.us/raw/7nH9wSpgqO

gettimeofday() and read() are called A LOT

Oops hit submit too soon, here's the output from strace -fcp after a short run http://p.sldr.us/raw/YSnEAiOb

(In reply to comment #12)
> Grub still has an entry for 3.3.7-1.fc16.x86_64 for me, where gnome-shell
> runs at about 30-40% CPU. Unsure if that helps anybody.

I guess that could be a part of the explanation. You are using an old initramfs that might be slightly incompatible with f17 systemd or file locations after usr-move.

Please run something like
  grub2-install /dev/sda
  grub2-mkconfig -o /boot/grub2/grub.cfg
and reboot.

Well now grub just says Fedora and advanced Fedora (paraphrasing) and has a fancy boot animation... that's new. gnome-shell is still running high though, ~85% on all 3 cores.

For the record, I was booting into the entry for 3.3.7-1.fc17.x86_64 every time except that once just to look at CPU usage there.

Also a reminder that I'm running this in Virtualbox, so I can fusker with a few hardware settings if I need to.

Just did a fresh install of Fedora 17 and now I'm hitting the problem again. Must be a problem with Virtualbox Guest Additions interacting with it.

I upgraded an F16 system (real HW, not a VM) to F17, then did a "yum update", and had this problem, as well as sound problems.  Tried stuff suggested here, didn't help.

Did a fresh install of F17, was working fine, with only the usual Gnome Shell lossage, no excessive CPU.  Then did a "yum update", and it's back to using >100% CPU again.

Thought that possibly the 3.4.4 kernel might have something to do with this or my sound problems, so rebooted to 3.3.4, and that hasn't helped anything.  So I think something in the other 419 packages that "yum update" updated is the culprit, but I don't know how to track it down without spending an insane amount of time on it.

I verified that after doing a "yum history undo" to roll back the previous "yum upgrade", so that I am back to the original F17 package set, Gnome Shell no longer sucks up >100% of the CPU.  Something in the updates repository other than the kernel is responsible for breaking this.

I've tracked down which package update breaks this on my F17 system.  When using systemd{,-sysv}-44-8, which was the original F17 version, Gnome Shell has reasonable CPU utilization.  When upgraded to systemd{,-sysv}-44-17, the Gnome Shell CPU utilization goes through the roof.

One difference between the two situations is that systemd-loginctl shows a user session when using 44-8:

    [eric@p1 ~]$ systemd-loginctl
       SESSION        UID USER             SEAT            
             2       1000 eric             seat0           

    1 sessions listed.

But no session when using 44-17:

    [eric@p1 ~]$ systemd-loginctl
       SESSION        UID USER             SEAT            

    0 sessions listed.

I'd suggest that other people having this CPU utilization problem check their systemd-loginctl output, to see if they too are missing a session.

Session exists for me, I'm fully up-to-date according to Software Update.

I've given this VM 3 cores and it looks like gnome-shell idles at a normal level with just terminal open and top running. If I open System Monitor, top reports gnome-shell instantly spiking to around 150% CPU and System Monitor shows the same. It floats around 120-150% until I close System Monitor.

Launching other programs cause it to spike high every now and then, but nothing nearly as bad.

Since my problem apparently has a completely different root cause than that of other people with the CPU >100% problem, and mine has been isolated to a problem with systemd session creation, I have created bug #839736 to track my issue.

I had the same issue, but from the start I noticed it had first occurred during watching videos on youtube. After closing youtube, CPU-load would come down to "only" about 100-120%, after closing the browser (Firefox), it would come down to ~20-25% after a short while. This was enough to keep the fan running higher than normal, and the latter would only come down to normal (inaudible) levels after closing the System Monitor (sorry, I'm not much of an expert, I am helpless without graphical tools).
...all together, these seemed to indicate to me some software graphics rendering was causing the high CPU load (albeit the System Monitor reporting it for the "Gnome Shell" task). Even the animated "Resources" view in the System Monitor seemed to be enough to keep CPU at >20%.
My laptop has a secondary Nvidia graphics card, so I decided to install the proprietary drivers instead of nouveau.
- which seems to have solved the issue. System Monitor reports ~5% CPU load when idle now, and watching videos hardly raises it at all...
Sorry I can't offer much information on the exact cause of the original problem, this is just a workaround with proprietary software.

Dell Latitude e6420, Intel i7 2720QM, 16GB RAM, Graphics integrated Intel and a Nvidia NVS 4200M, freshly installed (and updated) Fedora 17 64Bit with Gnome 3.4.2 on a 3.5.4-1.fc17.x86_64 Kernel

This just started to happen in my laptop.

Using fedora 18 up to date.

Nombre        : gnome-shell
Arquitectura        : x86_64
Versión     : 3.6.1
Lanzamiento     : 3.fc18
Tamaño        : 4.6 M
Repositorio        : installed
Desde el repositorio   : updates-testing

Happens to me on F18 too; should we open a separate bug for it or discuss it on the same bug?

systemd-195-5.fc18.x86_64
gnome-shell-3.6.1-3.fc18.x86_64
kernel-3.6.2-2.fc18.x86_64
kernel-3.6.3-3.fc18.x86_64
kernel-3.6.5-2.fc18.x86_64
xorg-x11-server-Xorg-1.13.0-7.fc18.x86_64
xorg-x11-drv-intel-2.20.12-1.fc18.x86_64

(problem occurs with both 3.6.3 and 3.6.5 kernels; trying going back to 3.6.2 next)

In my case, systemd-loginctl shows one session, so it's not that problem. I freshly installed F17 a couple of weeks ago and immediately upgraded to F18 using yum (without even logging in to GNOME once) so it's not any leftover F17 cruft either.

That certainly explains why my laptop would sometimes run out of battery completely if I only plug it in when it's down to 5% or so -- I get 40%-260+% CPU usage on a dual core + HT Core i5 ULV system, Intel graphics, with only a single tab of Chrome open and not using Flash.

Michel and javiermon, regarding the F18 issue: can you check what 'glxinfo | grep render' says? If it's using llvmpipe, you are likely hitting bug #870695.

(In reply to comment #25)
> Michel and javiermon, regarding the F18 issue: can you check what 'glxinfo |
> grep render' says? If it's using llvmpipe, you are likely hitting bug
> #870695.

Not using llvmpipe. Besides, given that llvmpipe is the only "fallback" option for GNOME 3.8, shouldn't we be worried if on a relatively recent laptop CPU consumption is still so high?

$ glxinfo | grep render
direct rendering: Yes
OpenGL renderer string: Mesa DRI Intel(R) Ironlake Mobile 
    GL_NV_conditional_render, GL_ARB_ES2_compatibility, GL_ARB_debug_output,

Hi

In my case it was bug #870695. Now fixed with the upgrade and then running /usr/libexec/plymouth/plymouth-update-initrd

Thanks,

That might have been my problem as well - with the Plymouth update (I didn't have to run update-initrd by hand) now gnome-shell takes < 1% CPU when idle.

Thanks, javiermon, that solved my problem too!.

Hi, with last update (kernel 3.7.3-101.fc17.x86_64 and gnome-shell-3.4.1-6) the problem appears again:


[jota@jotadesk ~]$ top -b -d 5 | grep gnome-shell
 1213 jota      20   0 1830m 206m  36m S 21.5  5.3   3:57.15 gnome-shell                                                                                      
 2010 jota      20   0 1791m 101m  34m S  3.9  2.6   1:10.04 gnome-shell                                                                                      
 1349 jota      20   0  537m  11m 7260 S  0.0  0.3   0:00.05 gnome-shell-cal                                                                                  
 2141 jota      20   0  537m 9836 7260 S  0.0  0.2   0:00.05 gnome-shell-cal                                                                                  


 1213 jota      20   0 1831m 207m  36m S 28.1  5.3   3:58.56 gnome-shell                                                                                      
 2010 jota      20   0 1791m 101m  34m S  4.0  2.6   1:10.24 gnome-shell                                                                                      
 1349 jota      20   0  537m  11m 7260 S  0.0  0.3   0:00.05 gnome-shell-cal                                                                                  
 2141 jota      20   0  537m 9836 7260 S  0.0  0.2   0:00.05 gnome-shell-cal                                                                                  


 1213 jota      20   0 1831m 207m  36m S 30.5  5.3   4:00.09 gnome-shell                                                                                      
 2010 jota      20   0 1791m 101m  34m S  2.8  2.6   1:10.38 gnome-shell                                                                                      
 1349 jota      20   0  537m  11m 7260 S  0.0  0.3   0:00.05 gnome-shell-cal                                                                                  
 2141 jota      20   0  537m 9836 7260 S  0.0  0.2   0:00.05 gnome-shell-cal                                                                                  


 1213 jota      20   0 1831m 207m  36m S 25.1  5.3   4:01.35 gnome-shell                                                                                      
 2010 jota      20   0 1791m 101m  34m S  3.8  2.6   1:10.57 gnome-shell                                                                                      
 1349 jota      20   0  537m  11m 7260 S  0.0  0.3   0:00.05 gnome-shell-cal                                                                                  
 2141 jota      20   0  537m 9836 7260 S  0.0  0.2   0:00.05 gnome-shell-cal                                                                                  


 1213 jota      20   0 1832m 209m  36m S 30.1  5.4   4:02.86 gnome-shell                                                                                      
 2010 jota      20   0 1791m 101m  34m S  3.6  2.6   1:10.75 gnome-shell                                                                                      
 1349 jota      20   0  537m  11m 7260 S  0.0  0.3   0:00.05 gnome-shell-cal                                                                                  
 2141 jota      20   0  537m 9836 7260 S  0.0  0.2   0:00.05 gnome-shell-cal                                                                                  


 1213 jota      20   0 1832m 209m  36m S 28.1  5.4   4:04.27 gnome-shell                                                                                      
 2010 jota      20   0 1791m 101m  34m S  5.0  2.6   1:11.00 gnome-shell                                                                                      
 1349 jota      20   0  537m  11m 7260 S  0.0  0.3   0:00.05 gnome-shell-cal                                                                                  
 2141 jota      20   0  537m 9836 7260 S  0.0  0.2   0:00.05 gnome-shell-cal                                                                                  


 1213 jota      20   0 1832m 209m  36m S 28.1  5.4   4:05.68 gnome-shell                                                                                      
 2010 jota      20   0 1791m 101m  34m S  4.0  2.6   1:11.20 gnome-shell                                                                                      
 1349 jota      20   0  537m  11m 7260 S  0.0  0.3   0:00.05 gnome-shell-cal                                                                                  
 2141 jota      20   0  537m 9836 7260 S  0.0  0.2   0:00.05 gnome-shell-cal

...

gnome-shell is always between 20% and 30% and sometimes higher 30%

I have executed /usr/libexec/plymouth/plymouth-update-initrd with no results.

Same here on a fresh Fedora 18 install, plymoth is up to date, even tried the plymouth-update-initrd 

Also reportetd to:
http://forums.fedoraforum.org/showthread.php?t=288526

(In reply to comment #31)
> http://forums.fedoraforum.org/showthread.php?t=288526

I also see this symptom on a MacBookPro10,1 retina using nouveau.

Any hints? Funny enough my system is the same as Mads's.

Mads's - did you try with nvidia drivers also?

(In reply to comment #33)
> Mads's - did you try with nvidia drivers also?

The evil drivers didn't for me at all. Don't know why.

Other observation: powertop shows 400+ wakeups/second in gnome-shell. I assume someone familiar with gnome-shell internals would be able to spot what it is doing and what is causing it.

For now I use xfce instead.

(In reply to comment #34)
> The evil drivers didn't for me at all. Don't know why.

Might be an UEFI issue, but reason I asked is to track down pontential dependencies for this issue especially as we are facing a very high resolution with our boxes which is something gnome might get crazy about...

> For now I use xfce instead.

And the high load is not there anymore? So this proves this issue is specific to gnome-shell!?
Sorry for OT again: Is xfce supporting all the special keys on your MBPr?

Using cinnamon instead of gnome3 is not an workaround as there is no gnome-shell anymore but cinnamon eating up the system instead. I've the feeling it is even worse than gnome-shell...

The problem is still present after the latest upgrades
Plymouth 0.8.8-5.fc18

Mar 11 10:16 initramfs-3.8.2-206.fc18.x86_64.img

glxinfo|fgrep render
direct rendering: Yes
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x301)
    GL_NV_blend_square, GL_NV_conditional_render, GL_NV_fog_distance, 

00:02.0 VGA compatible controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller (rev 02)
00:02.1 Display controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller (rev 02)

/etc/pam.d/system-auth
-session     optional      pam_systemd.so

gnome-shell 3.6.3.1-1.fc18 

llvmpipe ought not be the problem as a lot of CPU is used withouth any rendering on the screen.

FWIW, with the latest f18 testing updates I don't see the problem on my MacBookPro10,1.

The nouveau-drivers always got tons of errors, so i installed the 64-bit nvidia-driver from rpmfusion. 

Since then, gnome-shell goes up to short peaks at about 40%

I will check the next days, if my system still freezes with gnome-shell having lots of load.

(In reply to comment #38)
> gnome-shell 3.6.3.1-1.fc18 
> 
> llvmpipe ought not be the problem as a lot of CPU is used withouth any
> rendering on the screen.

Further investigating is showing, that gnome-shell is settling down after using 
ctrl-alt-F2 to another screen in text mode.

I have made a lot of things to avoid using GNOME3, primarily installing Xfce4 and switching display manager to lightdm

It now appears, that using lightdm and a Gnome3 session no longer is causing the system to use sofware rendering by llvmpipe (checked by glxinfo|fgrep render) 
(it is an ATOM D510 based system with embedded graphics using the intel/i915 driver)

It may not be relevant, but I also added video=LVDS-1:d as a the kernel boot parameter avoiding using an incorrectly detected screen i.e. no logon window appeared, only the background (probably caused by using a KVM switch for several PCs)

Had the problem on F18 as well.

My hw is similar to Joergen's:
00:02.0 VGA compatible controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller (rev 02)

Up to 250% cpu for gnome-shell which made the system (Dual Atom 1.8Ghz, 4Gb RAM) unusable (typing in local gnome-terminal with extreme latency)

Found out that nomodeset on cmdline forces Xorg to detect vesa instead of intel.
[    20.352] (II) LoadModule: "vesa"
[    20.353] (II) Loading /usr/lib64/xorg/modules/drivers/vesa_drv.so
[    20.391] (II) Module vesa: vendor="X.Org Foundation"

This leads to llvmpipe software rendering, which makes the desktop unusable.

Removing nomodeset and adding "xdriver=intel video=LVDS-1:d " to cmdline solved the problem for me (video=LVDS-1:d to fix the same problem Joergen had.)

Now Xorg detects the intel driver and everything is fine:
# glxinfo| grep render
direct rendering: Yes
OpenGL renderer string: Mesa DRI Intel(R) IGD

See this same behavior in F19 beta. gnome-shell settles down immediately after switching to a text console.

This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

I'm seeing this on F18 (updated) running it on Parallels as a VM.

I'm still seeing this on the latest F18 (3.9.6-200.fc18.i686, updated).

Booting without "nomodeset" in the kernel command line avoids the problem for me.

Word of caution: I have removed that from GRUB_CMDLINE_LINUX in /etc/default/grub, have edited /boot/grub2/grub.cfg to remove 'nomodeset', and await the grub magic to properly migrate /etc/default/grub to /boot/grub2/grub.cfg ('mv /boot/grub2/grub.cfg /boot/grub2/grub.cfg-$(date +%Y%m%d-%H%M%S) && grub2-mkconfig -o /boot/grub2/grub.cfg' just rendered my system unbootable).

(In reply to Gunnar Hellekson from comment #43)
> See this same behavior in F19 beta. gnome-shell settles down immediately
> after switching to a text console.

I get the exact same behavior on F19. Switching to text console does help speed up the recovery.

One thing to note, my Gnome 3 spikes to 100% CPU and locks my current X session right after receiving an event (such as an IM in pidgen or popup from Chrome) that causes a notification to trigger. The lock up normally lasts one minute with gnome-shell pegging 100% CPU.

Upgraded from F17 to F19 using FedUp. Has similar behavior. With just the laptop's monitor it is OK. Attaching an external, second monitor causes gnome-shell process to use CPU at around 100% to 160% CPU (dual core machine). Seems to last indefinitely. Using 'renice 20 PID' causes gnome-shell to run at about 90% CPU (on one core). Removing external monitor causes behavior to disappear. Seems to occur in both Gnome and Gnome classic. Version 3.8.4. Did not notice this in F17.

With one monitor gnome-shell uses ~20% CPU.

Switch to KDM and the problem remains. (yum install kdm;systemctl enable kdm.service;systemctl disable gdm.service;)

And then switch to LXDE (which was installed quite some time ago) resolves the issue. Two monitors runs as expected. Process "X" runs at about ~2% CPU, ~95% idle. 3.10.5-201.fc19.i686, integrated Intel 945GM.

I am affected by this bug in Fedora 20. It is amazing that we still have not figured this out.
I am connected via VNC and look:
KiB Swap: 12394492 total,        0 used, 12394492 free,  2968108 cached

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 3324 smbuser   20   0 1035252  42340  25124 R  80.1  0.2  26:00.93 /usr/libexec/gnome-initial-setup
 1025 root      20   0  178292  17060   7828 R  27.9  0.1   9:17.47 /usr/bin/Xorg :0 -background none -verbose -auth /run/gdm/auth-for-gdm-v0AvFu/da+
 3466 smbuser   20   0  478844  13340   9480 S   6.3  0.1   1:58.98 /usr/libexec/gnome-session-failed --allow-logout
 
As you can see,gnome-initial-setup is eating 80% of a core, and Xorg is taking an addtional 30%. Completely unacceptable.

Any idea?

I am now seeing this on Fedora 20. I did not have the problem on Fedora 19.

Anyone know anything?

Seems to be related: https://bugzilla.gnome.org/show_bug.cgi?id=719418

Still seeing this problem on an F17 machine:

# top

top - 21:45:20 up 20 days, 10:52,  5 users,  load average: 6.30, 4.24, 3.65
Tasks: 274 total,   2 running, 271 sleeping,   0 stopped,   1 zombie
Cpu(s): 13.5%us,  5.8%sy,  0.0%ni, 80.0%id,  0.3%wa,  0.3%hi,  0.1%si,  0.0%st
Mem:  32842188k total, 32237528k used,   604660k free,   115152k buffers
Swap: 67076092k total,  1051676k used, 66024416k free,   679320k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                            
 7261 gerryr    20   0 1735m 177m  16m S 475.2  0.6  12617:11 gnome-shell

$ glxinfo | grep renderer
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x300)

This machine has an Intel HD P4000 GPU so why is it using llvmpipe?

gnome-shell is wrecking this machine.

Re: comment 53 - F17 is no longer supported.

That said, people are still seeing gnome-shell consume inordinate amounts of memory (https://bugzilla.redhat.com/show_bug.cgi?id=977387) and/or cpu in supported releases, particularly on machines with modest resources.  It's not clear if anyone upstream is considering any patches to help (if so, I haven't seen any).

Workarounds include using a different desktop environment, and manually using alt+r periodically.

Same problem. Freshly installed Fedora 20 machine.

In comment 54, of course I meant alt-f2 + r (not alt + r).

I am now having this problem with Fedora 20.  I didn't have it with 17, or 19 (did not try 18).

Created attachment 900260 [details]
lspci

Me too, on F20. Happens only when Chrome is open.

It would be really helpful to find out what functions gnome-shell is spending its time in when this happens.  On a machine this problem is occurring on install the debuginfo related to gnome shell and perf with:

# debuginfo-install gnome-shell -y
# yum install perf -y

When the problem occurs again run the following to see where gnome-shell is spending time :

# perf top

To limit perf to monitoring gnome-shell you could do:

# perf top -p `pgrep -d "," gnome-shell`

Created attachment 900693 [details]
perf screenshot

Here you go, William.

Another piece of info is that Chrome was also consuming ~80% CPU on plain web pages, until I disabled everything related to GPU in chrome://flags

If I close Chrome, gnome-shell also stops using CPU.

Those functions look pretty generic.  It might be useful to get call profiles with callstack for both gnome-shell and chrome.  

When the gnome-shell high load is occurring run the following for several seconds as root:

perf record -g -p `pgrep -d "," gnome-shell` -o gnome-shell.data

Then write the date out in human readable form:

 perf report -i gnome-shell.data --stdio > gnome-shell.profile


Given that Chrome is also having a lot of load maybe also do something similar for it:

 perf record -g -p `pgrep -d "," chrome` -o chrome.data

Then output the data:

perf report -i chrome.data --stdio > chrome.profile


However, it is possible that chrome is dynamically generating code and there is just going to be a bunch of hex addresses that are not going to be too useful.

Could it be that there is a badly behaving html page that chrome is trying to render?  Maybe try narrowing down which tab is the offending one and then use the javascript profiler on https://developer.chrome.com/devtools/docs/cpu-profiling to find out what is going on.

Created attachment 901031 [details]
gnome-shell.profile

#  perf report -i gnome-shell.data --stdio > gnome-shell.profile
Failed to open /tmp/perf-1497.map, continuing without symbols
Failed to open [vsyscall], continuing without symbols

Chrome no longer uses CPU constantly after I disabled everything related to GPU in chrome://flags

Thanks

Created attachment 901200 [details]
perf profile of gnome-shell using high CPU

Here is the perf profile for the gnome-shell session using high CPU (> 30% in a dual cpu system) in my case.  This is associated with increased memory usage (~700 MB RES at the time of the perf record) where I usually do 'alt-f2 r' to keep the laptop from running hotter.  But if I don't, memory and cpu usage continue to grow and eventually the session begins to become unresponsive.

So in my case, it seems pretty clearly associated with symptoms that have the appearance of a memory leak.

Still happens to me as well after Fed20 upgrade with Chrome open.
The workstation is so frozen that I rarely even get a chance to be able to do a Alt+F2 r, so I've to restart gdm and loose all my workspace :(

Linux stormbringer 3.15.10-200.fc20.x86_64 #1 SMP Thu Aug 14 15:39:24 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

In my case, from 15% to 25% CPU is constantly consumed by gnome-shell.  RHEL 7 on ThinkPad X230.  When I switch to text terminal by Ctrl-Alt-F2, it stops.

# uname -a
Linux ontpx230 3.10.0-123.13.2.el7.x86_64 #1 SMP Fri Dec 12 19:51:03 EST 2014 x86_64 x86_64 x86_64 GNU/Linux

# debuginfo-install gnome-shell -y
# perf top -p `pgrep -d "," gnome-shell`
  5.17%  libclutter-1.0.so.0.1404.0          [.] clutter_actor_get_type
  5.15%  i965_dri.so                         [.] 0x0000000000011ce1
  3.62%  libglib-2.0.so.0.3600.3             [.] g_source_iter_next
  2.57%  libglib-2.0.so.0.3600.3             [.] g_hash_table_lookup
  2.28%  libgobject-2.0.so.0.3600.3          [.] g_type_check_instance_is_a
  2.05%  libglib-2.0.so.0.3600.3             [.] g_mutex_get_impl
  1.34%  libclutter-1.0.so.0.1404.0          [.] _clutter_actor_get_stage_internal
  1.34%  libpthread-2.17.so                  [.] pthread_mutex_lock
...

# pstack $THE_PID
...
Thread 1 (Thread 0x7f1ab81e0a00 (LWP 17191)):
#0  0x00007f1aae55fbdd in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f1aac3c9f72 in _xcb_conn_wait () from /lib64/libxcb.so.1
#2  0x00007f1aac3cb42f in wait_for_reply () from /lib64/libxcb.so.1
#3  0x00007f1aac3cb542 in xcb_wait_for_reply () from /lib64/libxcb.so.1
#4  0x00007f1ab0cc7eff in _XReply (dpy=0x17cd040, rep=0x7fffd04dab20, extra=0, discard=0) at xcb_io.c:602
#5  0x00007f1aa7d5682b in DRI2GetBuffersWithFormat () from /lib64/libGL.so.1
#6  0x00007f1aa7d5415b in dri2GetBuffersWithFormat () from /lib64/libGL.so.1
#7  0x00007f1a9c2b2f31 in intel_update_renderbuffers () from /usr/lib64/dri/i965_dri.so
#8  0x00007f1a9c2b3223 in intel_prepare_render () from /usr/lib64/dri/i965_dri.so
#9  0x00007f1a9c2d26bf in brw_draw_prims () from /usr/lib64/dri/i965_dri.so
#10 0x00007f1a97b56cc0 in vbo_draw_arrays () from /lib64/libdricore9.2.5.so.1
#11 0x00007f1ab21afdc8 in _cogl_framebuffer_gl_draw_attributes (framebuffer=0x2f4ac10, pipeline=<optimized out>, mode=7, first_vertex=0, n_vertices=4, attributes=<optimized out>, n_attributes=2, flags=(COGL_DRAW_SKIP_JOURNAL_FLUSH | COGL_DRAW_SKIP_PIPELINE_VALIDATION | COGL_DRAW_SKIP_FRAMEBUFFER_FLUSH | COGL_DRAW_SKIP_LEGACY_STATE | COGL_DRAW_COLOR_ATTRIBUTE_IS_OPAQUE)) at driver/gl/cogl-framebuffer-gl.c:1071
#12 0x00007f1ab21fa916 in _cogl_journal_flush_modelview_and_entries (batch_start=<optimized out>, batch_len=1, data=0x7fffd04dafa0) at ./cogl-journal.c:305
#13 0x00007f1ab21fa6b4 in _cogl_journal_flush_texcoord_vbo_offsets_and_entries (batch_start=0x5264000, batch_len=1, data=0x7fffd04dafa0) at ./cogl-journal.c:556
#14 0x00007f1ab21fa539 in _cogl_journal_flush_vbo_offsets_and_entries (batch_start=0x5264000, batch_len=1, data=<optimized out>) at ./cogl-journal.c:663
#15 0x00007f1ab21fbb53 in _cogl_journal_flush (journal=0x1810c20) at ./cogl-journal.c:1375
#16 0x00007f1ab21fcb0c in _cogl_framebuffer_flush_journal (framebuffer=framebuffer@entry=0x2f4ac10) at ./cogl-framebuffer.c:595
#17 0x00007f1ab21fd623 in cogl_framebuffer_clear4f (framebuffer=0x2f4ac10, buffers=2, red=0.180392161, green=0.203921571, green@entry=0, blue=0.211764708, blue@entry=-1.38038149e+10, alpha=1, alpha@entry=4.59163468e-41) at ./cogl-framebuffer.c:339
#18 0x00007f1ab21fd988 in cogl_framebuffer_clear (framebuffer=<optimized out>, buffers=<optimized out>, color=color@entry=0x7fffd04db160) at ./cogl-framebuffer.c:440
#19 0x00007f1ab21c89c5 in cogl_clear (color=color@entry=0x7fffd04db160, buffers=<optimized out>) at ./cogl.c:87
#20 0x00007f1ab2b1fd79 in clutter_stage_paint (self=0x2f62eb0) at ./clutter-stage.c:720
#21 0x00007f1aaeb6dd27 in _g_closure_invoke_va (closure=closure@entry=0x2f65e60, return_value=return_value@entry=0x0, instance=instance@entry=0x2f62eb0, args=args@entry=0x7fffd04db390, n_params=0, param_types=0x0) at gclosure.c:840
#22 0x00007f1aaeb8658d in g_signal_emit_valist (instance=0x2f62eb0, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffd04db390) at gsignal.c:3234
#23 0x00007f1aaeb8723f in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3384
#24 0x00007f1ab2ac61f9 in clutter_actor_continue_paint (self=0x2f62eb0) at ./clutter-actor.c:3892
#25 0x00007f1ab2acc5dd in clutter_actor_paint (self=self@entry=0x2f62eb0) at ./clutter-actor.c:3816
#26 0x00007f1ab2b23e7c in _clutter_stage_do_paint (stage=stage@entry=0x2f62eb0, clip=clip@entry=0x0) at ./clutter-stage.c:676
#27 0x00007f1ab2abce40 in clutter_stage_cogl_redraw (stage_window=0x1810b70) at cogl/clutter-stage-cogl.c:559
#28 0x00007f1ab2b227b3 in clutter_stage_do_redraw (stage=0x2f62eb0) at ./clutter-stage.c:1180
#29 _clutter_stage_do_update (stage=0x2f62eb0) at ./clutter-stage.c:1238
#30 0x00007f1ab2b087f8 in master_clock_update_stages (master_clock=0x2ebeb80, stages=0x5bc8290 = {...}) at ./clutter-master-clock.c:457
#31 clutter_clock_dispatch (source=source@entry=0x2eccda0, callback=<optimized out>, user_data=<optimized out>) at ./clutter-master-clock.c:589
#32 0x00007f1aae87dac6 in g_main_dispatch (context=0x17aad80) at gmain.c:3058
#33 g_main_context_dispatch (context=context@entry=0x17aad80) at gmain.c:3634
#34 0x00007f1aae87de48 in g_main_context_iterate (context=0x17aad80, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3705
#35 0x00007f1aae87e25a in g_main_loop_run (loop=0x17ad9c0) at gmain.c:3899
#36 0x00007f1ab76cee78 in meta_run () at core/main.c:556
#37 0x0000000000401f20 in main (argc=1, argv=0x7fffd04dbac8) at main.c:412

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

I'm having this problem with an Intel video card and F22.

$ rpm -q gnome-shell
gnome-shell-3.16.4-1.fc22.x86_64

$ glxinfo | grep render
direct rendering: Yes
    GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
    GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile 
    GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth, 
    GL_NV_conditional_render, GL_NV_depth_clamp, GL_NV_packed_depth_stencil, 
    GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth, 
    GL_NV_blend_square, GL_NV_conditional_render, GL_NV_depth_clamp, 
    GL_OES_fbo_render_mipmap, GL_OES_get_program_binary, GL_OES_mapbuffer,

$ top -b -n 1
top - 00:08:16 up 56 min,  3 users,  load average: 0,85, 0,76, 0,78
Tasks: 205 total,   2 running, 203 sleeping,   0 stopped,   0 zombie
%Cpu(s): 17,0 us,  1,0 sy,  0,0 ni, 80,1 id,  1,8 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Mem :  3743772 total,  1980016 free,   726396 used,  1037360 buff/cache
KiB Swap:   128516 total,   128516 free,        0 used.  2792628 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 3915 massi     20   0 1559740 139312  57484 R 100,0  3,7   9:33.34 gnome-shell
    1 root      20   0  191352   5692   3924 S   0,0  0,2   0:01.28 systemd
    2 root      20   0       0      0      0 S   0,0  0,0   0:00.00 kthreadd
    3 root      20   0       0      0      0 S   0,0  0,0   0:00.11 ksoftirqd/0

If I switch to a text console the CPU slows down immediatly. No background extension enabled.
Does anyone have this problem?