This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 812624

Summary: Gnome Shell constantly using > 100% cpu load
Product: [Fedora] Fedora Reporter: Anthony Altemara <aaltemara>
Component: gnome-shellAssignee: Owen Taylor <otaylor>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 20CC: aquarichy, bpeck, bugzilla, collura, cyril, davidshumway, dblechte, dergeologiker, dhgutteridge, eric-bugs2, ghelleks, greno, iweiss, jjprieto, jones, jth, kalevlember, leho, longint, lsof, mads, marius.andreiana, martin, massi.ergosum, maurizio.antillon, maxamillion, mcdavey, michel, mszpak, mzdunek, nickstoughton, onagano, otaylor, pereira.vitor.manuel, peter.hutterer, phaleintx, philipp, pstadt, ptg, rob.kleingunnewiek, rstrode, ryniker, sales, samkraju, sstolarski, tristan, txn2tahx3v, walters, wcohen
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-06-29 07:38:17 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
Attached is output of strace of gnome-shell process that has the high CPU: strace -p 1671
none
gnome shell strace
none
strace after mkdir -p for inotify
none
lspci
none
perf screenshot
none
gnome-shell.profile
none
perf profile of gnome-shell using high CPU none

Description Anthony Altemara 2012-04-15 10:10:58 EDT
Created attachment 577541 [details]
Attached is output of strace of gnome-shell process that has the high CPU:  strace -p 1671

Description of problem:
With only a web browser open, and little activity, gnome-shell is constantly using > 100% CPU (as shown by top).

Version-Release number of selected component (if applicable):
 gnome-shell-3.4.0-1.fc17.x86_64


How reproducible:
Always


Steps to Reproduce:
1. Boot the system
2. Open Chrome
3.
  
Actual results:
gnome-shell uses > 100% CPU

Expected results:
gnome-shell doesn't hog the system


Additional info:
uptime
10:07:25 up 11 min,  2 users,  load average: 1.75, 1.48, 1.00

ps aux
[root@e6510 anthony]# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.1  0.0  41660  4472 ?        Ss   09:55   0:01 /usr/lib/systemd/systemd
root         2  0.0  0.0      0     0 ?        S    09:55   0:00 [kthreadd]
root         3  0.0  0.0      0     0 ?        S    09:55   0:00 [ksoftirqd/0]
root         6  0.0  0.0      0     0 ?        S    09:55   0:00 [migration/0]
root         7  0.0  0.0      0     0 ?        S    09:55   0:00 [watchdog/0]
root         8  0.0  0.0      0     0 ?        S    09:55   0:00 [migration/1]
root        10  0.0  0.0      0     0 ?        S    09:55   0:00 [ksoftirqd/1]
root        11  0.0  0.0      0     0 ?        S    09:55   0:00 [kworker/0:1]
root        12  0.0  0.0      0     0 ?        S    09:55   0:00 [watchdog/1]
root        13  0.0  0.0      0     0 ?        S    09:55   0:00 [migration/2]
root        15  0.0  0.0      0     0 ?        S    09:55   0:00 [ksoftirqd/2]
root        16  0.0  0.0      0     0 ?        S    09:55   0:00 [watchdog/2]
root        17  0.0  0.0      0     0 ?        S    09:55   0:00 [migration/3]
root        19  0.0  0.0      0     0 ?        S    09:55   0:00 [ksoftirqd/3]
root        20  0.0  0.0      0     0 ?        S    09:55   0:00 [watchdog/3]
root        21  0.0  0.0      0     0 ?        S<   09:55   0:00 [cpuset]
root        22  0.0  0.0      0     0 ?        S<   09:55   0:00 [khelper]
root        23  0.0  0.0      0     0 ?        S    09:55   0:00 [kdevtmpfs]
root        24  0.0  0.0      0     0 ?        S<   09:55   0:00 [netns]
root        25  0.0  0.0      0     0 ?        S    09:55   0:00 [sync_supers]
root        26  0.0  0.0      0     0 ?        S    09:55   0:00 [bdi-default]
root        27  0.0  0.0      0     0 ?        S<   09:55   0:00 [kintegrityd]
root        28  0.0  0.0      0     0 ?        S<   09:55   0:00 [kblockd]
root        29  0.0  0.0      0     0 ?        S<   09:55   0:00 [ata_sff]
root        30  0.0  0.0      0     0 ?        S    09:55   0:00 [khubd]
root        31  0.0  0.0      0     0 ?        S<   09:55   0:00 [md]
root        32  0.1  0.0      0     0 ?        S    09:55   0:01 [kworker/1:1]
root        34  0.0  0.0      0     0 ?        S    09:55   0:00 [kswapd0]
root        35  0.0  0.0      0     0 ?        SN   09:55   0:00 [ksmd]
root        36  0.0  0.0      0     0 ?        SN   09:55   0:00 [khugepaged]
root        37  0.0  0.0      0     0 ?        S    09:55   0:00 [fsnotify_mark]
root        38  0.0  0.0      0     0 ?        S<   09:55   0:00 [crypto]
root        44  0.0  0.0      0     0 ?        S<   09:55   0:00 [kthrotld]
root        47  0.0  0.0      0     0 ?        S    09:55   0:00 [scsi_eh_0]
root        48  0.0  0.0      0     0 ?        S    09:55   0:00 [scsi_eh_1]
root        49  0.0  0.0      0     0 ?        S    09:55   0:00 [scsi_eh_2]
root        50  0.0  0.0      0     0 ?        S    09:55   0:00 [scsi_eh_3]
root        51  0.0  0.0      0     0 ?        S    09:55   0:00 [scsi_eh_4]
root        52  0.0  0.0      0     0 ?        S    09:55   0:00 [scsi_eh_5]
root        55  0.0  0.0      0     0 ?        S    09:55   0:00 [kworker/u:4]
root        56  0.0  0.0      0     0 ?        S    09:55   0:00 [kworker/u:5]
root        57  0.0  0.0      0     0 ?        S    09:55   0:00 [kworker/u:6]
root        58  0.1  0.0      0     0 ?        S    09:55   0:00 [kworker/0:2]
root        59  0.0  0.0      0     0 ?        S<   09:55   0:00 [kpsmoused]
root        61  0.1  0.0      0     0 ?        S    09:55   0:01 [kworker/2:1]
root       155  0.0  0.0      0     0 ?        S    09:55   0:00 [kworker/1:2]
root       208  0.2  0.0      0     0 ?        S    09:55   0:01 [kworker/3:2]
root       225  0.0  0.0      0     0 ?        S<   09:55   0:00 [firewire]
root       246  0.0  0.0      0     0 ?        S    09:55   0:00 [pccardd]
root       279  0.0  0.0      0     0 ?        S    09:55   0:00 [jbd2/sda3-8]
root       280  0.0  0.0      0     0 ?        S<   09:55   0:00 [ext4-dio-unwrit]
root       312  0.0  0.0  30788  1572 ?        Ss   09:55   0:00 /usr/lib/systemd/systemd-journald
root       313  0.0  0.0      0     0 ?        S    09:55   0:00 [kauditd]
root       319  0.0  0.0  27960  2512 ?        Ss   09:55   0:00 /usr/lib/udev/udevd
root       353  0.0  0.0      0     0 ?        S<   09:55   0:00 [kvm-irqfd-clean]
root       356  0.0  0.0      0     0 ?        S    09:55   0:00 [flush-8:0]
root       473  0.0  0.0      0     0 ?        S    09:55   0:00 [ips-adjust]
root       474  0.0  0.0      0     0 ?        S    09:55   0:00 [ips-monitor]
root       485  0.0  0.0      0     0 ?        S<   09:55   0:00 [cfg80211]
root       488  0.0  0.0      0     0 ?        S<   09:55   0:00 [iwlwifi]
root       505  0.2  0.0      0     0 ?        S    09:55   0:01 [kworker/2:2]
root       509  0.0  0.0      0     0 ?        S<   09:55   0:00 [hd-audio0]
root       519  0.0  0.0      0     0 ?        S<   09:55   0:00 [hci0]
root       586  0.0  0.0      0     0 ?        S    09:56   0:00 [jbd2/sda2-8]
root       587  0.0  0.0      0     0 ?        S<   09:56   0:00 [ext4-dio-unwrit]
root       593  0.0  0.0      0     0 ?        S    09:56   0:00 [jbd2/sda5-8]
root       594  0.0  0.0      0     0 ?        S<   09:56   0:00 [ext4-dio-unwrit]
root       604  0.0  0.0  21040  2132 ?        Ss   09:56   0:00 /usr/sbin/bluetoothd -n
root       610  0.0  0.0  26204  1084 ?        S<sl 09:56   0:00 /sbin/auditd -n
root       625  0.0  0.0  80172   824 ?        S<sl 09:56   0:00 /sbin/audispd
root       629  0.0  0.0  21420   868 ?        S<   09:56   0:00 /usr/sbin/sedispatch
root       650  0.0  0.1 364816  7428 ?        Ssl  09:56   0:00 /usr/sbin/NetworkManager --no-daemon
root       657  0.0  0.0 122732  1236 ?        Ss   09:56   0:00 /usr/sbin/abrtd -d -s
avahi      666  0.0  0.0  28008  1704 ?        Ss   09:56   0:00 avahi-daemon: running [e6510.local]
root       667  0.0  0.0  21064   528 ?        Ss   09:56   0:00 /usr/sbin/irqbalance
avahi      670  0.0  0.0  27880   236 ?        S    09:56   0:00 avahi-daemon: chroot helper
root       671  0.0  0.0  16944   800 ?        Ss   09:56   0:00 /usr/sbin/atd -f
root       672  0.0  0.0  11564   312 ?        Ss   09:56   0:00 /usr/bin/system-setup-keyboard
root       676  0.0  0.0  26152  1368 ?        Ss   09:56   0:00 /usr/lib/systemd/systemd-logind
root       679  0.0  0.0   6436   852 ?        Ss   09:56   0:00 /usr/sbin/mcelog --ignorenodev --daemon --foreground
chrony     683  0.0  0.0  24540  1264 ?        S    09:56   0:00 /usr/sbin/chronyd -u chrony
dbus       686  0.0  0.0  22728  2432 ?        Ss   09:56   0:00 /bin/dbus-daemon --system --address=systemd: --nofork --systemd-activati
root       688  0.0  0.0 118388  1436 ?        Ss   09:56   0:00 /usr/sbin/crond -n
root       695  0.0  0.0 114192   824 ?        S    09:56   0:00 /bin/bash /usr/sbin/ksmtuned
root       702  0.0  0.0 251500  3744 ?        Ssl  09:56   0:00 /sbin/rsyslogd -n -c 5
root       705  0.0  0.0 220380  5184 ?        Sl   09:56   0:00 /usr/libexec/polkit-1/polkitd --no-debug
root       715  0.0  0.0      0     0 ?        S<   09:56   0:00 [iscsi_eh]
root       717  0.0  0.0      0     0 ?        S<   09:56   0:00 [ib_mcast]
root       718  0.0  0.0      0     0 ?        S<   09:56   0:00 [ib_cm]
root       719  0.0  0.0      0     0 ?        S<   09:56   0:00 [iw_cm_wq]
root       720  0.0  0.0      0     0 ?        S<   09:56   0:00 [ib_addr]
root       721  0.0  0.0      0     0 ?        S<   09:56   0:00 [rdma_cm]
root       727  0.0  0.0      0     0 ?        S<   09:56   0:00 [krfcommd]
root       728  0.0  0.0      0     0 ?        S<   09:56   0:00 [cnic_wq]
root       729  0.0  0.0      0     0 ?        S<   09:56   0:00 [bnx2i_thread/0]
root       730  0.0  0.0      0     0 ?        S<   09:56   0:00 [bnx2i_thread/1]
root       731  0.0  0.0      0     0 ?        S<   09:56   0:00 [bnx2i_thread/2]
root       732  0.0  0.0      0     0 ?        S<   09:56   0:00 [bnx2i_thread/3]
root       735  0.0  0.0  69020  2652 ?        S    09:56   0:00 /usr/sbin/modem-manager
root       737  0.0  0.0  16368  1292 ?        Ss   09:56   0:00 /usr/sbin/lldpad
root       742  0.0  0.0  22764   924 ?        Ss   09:56   0:00 /usr/sbin/xinetd -stayalive -pidfile /var/run/xinetd.pid
root       744  0.0  0.0  98784   328 ?        Ssl  09:56   0:00 iscsiuio
root       749  0.0  0.0  19160   896 ?        Ss   09:56   0:00 /sbin/rpcbind -w
root       751  0.0  0.0      0     0 ?        S<   09:56   0:00 [fc_exch_workque]
root       752  0.0  0.0      0     0 ?        S<   09:56   0:00 [fc_rport_eq]
root       756  0.0  0.0   5052   440 ?        Ss   09:56   0:00 iscsid
root       757  0.0  0.0   7948  3864 ?        S<Ls 09:56   0:00 iscsid
root       762  0.0  0.0      0     0 ?        S<   09:56   0:00 [rpciod]
rpcuser    765  0.0  0.0  23532  1372 ?        Ss   09:56   0:00 /sbin/rpc.statd
root       770  0.0  0.0      0     0 ?        S<   09:56   0:00 [fcoethread/0]
root       771  0.0  0.0      0     0 ?        S<   09:56   0:00 [fcoethread/1]
root       772  0.0  0.0      0     0 ?        S<   09:56   0:00 [fcoethread/2]
root       773  0.0  0.0      0     0 ?        S<   09:56   0:00 [fcoethread/3]
root       776  0.0  0.0   8540   348 ?        Ss   09:56   0:00 /usr/sbin/fcoemon --syslog
root       797  0.0  0.0  49504  1976 ?        Ss   09:56   0:00 /usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -B -
root       881  0.0  0.0 117220   756 ?        Ssl  09:56   0:00 /usr/lib/vmware/bin/vmware-vmblock-fuse -o subtype=vmware-vmblock,defaul
root       926  0.0  0.0   4720   468 ?        Ss   09:56   0:00 /usr/bin/vmnet-bridge -s 6 -d /var/run/vmnet-bridge-0.pid -n 0
root       934  0.0  0.0   4692   172 ?        Ss   09:56   0:00 /usr/bin/vmnet-netifup -s 6 -d /var/run/vmnet-netifup-vmnet1.pid /dev/vm
root       939  0.0  0.0  13820   336 ?        Ss   09:56   0:00 /usr/bin/vmnet-dhcpd -s 6 -cf /etc/vmware/vmnet1/dhcpd/dhcpd.conf -lf /e
root       942  0.0  0.0  11640  1060 ?        S    09:56   0:00 /usr/bin/vmnet-natd -s 6 -m /etc/vmware/vmnet8/nat.mac -c /etc/vmware/vm
root       944  0.0  0.0   4692   172 ?        Ss   09:56   0:00 /usr/bin/vmnet-netifup -s 6 -d /var/run/vmnet-netifup-vmnet8.pid /dev/vm
root       949  0.0  0.0  13820   336 ?        Ss   09:56   0:00 /usr/bin/vmnet-dhcpd -s 6 -cf /etc/vmware/vmnet8/dhcpd/dhcpd.conf -lf /e
root       961  0.0  0.0  23744   836 ?        Ss   09:56   0:00 /usr/sbin/vmware-authdlauncher
root      1011  0.0  0.0  23968  1780 ?        Ss   09:56   0:00 /usr/bin/vmware-usbarbitrator
root      1156  0.1  0.9 651084 55944 ?        Sl   09:56   0:00 /usr/lib/vmware/bin/vmware-hostd -a /etc/vmware/hostd/config.xml
root      1161  0.0  0.0 209680  2180 ?        Ssl  09:56   0:00 /usr/sbin/gdm-binary -nodaemon
root      1173  0.0  0.0 247468  4112 ?        Sl   09:56   0:00 /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Dis
root      1180 15.1  0.3 135572 19176 tty1     Ss+  09:56   1:45 /usr/bin/Xorg :0 -background none -logverbose 7 -auth /var/run/gdm/auth-
root      1240  0.0  0.0 317780  4168 ?        Ssl  09:56   0:00 /usr/libexec/accounts-daemon
root      1263  0.0  0.0 226392  4124 ?        Sl   09:56   0:00 /usr/libexec/upowerd
root      1293  0.0  0.1  88796  7340 ?        S    09:56   0:00 /sbin/dhclient -d -4 -sf /usr/libexec/nm-dhcp-client.action -pf /var/run
rtkit     1318  0.0  0.0 164560  1224 ?        SNsl 09:56   0:00 /usr/libexec/rtkit-daemon
root      1338  0.0  0.0 350484  4472 ?        Sl   09:56   0:00 gdm-session-worker [pam/gdm-password]
root      1372  0.0  0.0      0     0 ?        S    09:56   0:00 [scsi_eh_6]
root      1373  0.0  0.0      0     0 ?        S<   09:56   0:00 [iscsi_q_6]
root      1374  0.0  0.0      0     0 ?        S<   09:56   0:00 [scsi_wq_6]
root      1382  0.0  0.0  27956  1768 ?        S    09:56   0:00 /usr/lib/udev/udevd
root      1399  0.0  0.0  97648  2224 ?        Ss   09:56   0:00 sendmail: accepting connections
smmsp     1430  0.0  0.0  82700  1796 ?        Ss   09:56   0:00 sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue
anthony   1436  0.0  0.1 461616  7152 ?        SLl  09:56   0:00 /usr/bin/gnome-keyring-daemon --daemonize --login
anthony   1440  0.0  0.2 508736 13160 ?        Ssl  09:56   0:00 gnome-session
anthony   1457  0.0  0.0  20212   504 ?        S    09:56   0:00 dbus-launch --sh-syntax --exit-with-session
anthony   1458  0.1  0.0  23708  2240 ?        Ss   09:56   0:01 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
anthony   1519  0.0  0.0 322464  4584 ?        Sl   09:56   0:00 /usr/libexec/imsettings-daemon
anthony   1522  0.0  0.0 159032  2160 ?        S    09:56   0:00 /usr/libexec/gvfsd
anthony   1524  0.0  0.0 285084  3224 ?        Sl   09:56   0:00 /usr/libexec//gvfs-fuse-daemon -f /home/anthony/.gvfs
anthony   1616  0.1  0.3 892072 18296 ?        Sl   09:56   0:00 /usr/libexec/gnome-settings-daemon
anthony   1625  0.0  0.1 410980 10252 ?        Sl   09:56   0:00 /usr/bin/pulseaudio --start
anthony   1632  0.0  0.0 102892  2476 ?        S    09:56   0:00 /usr/libexec/pulse/gconf-helper
anthony   1634  0.0  0.0 137320  3300 ?        S    09:56   0:00 /usr/libexec/gconfd-2
root      1639  0.0  0.0 208932  4436 ?        Ss   09:56   0:00 /usr/sbin/cupsd -f
colord    1640  0.0  0.0 327312  5172 ?        Ssl  09:56   0:00 /usr/libexec/colord
colord    1643  0.0  0.1 493044  7620 ?        Ssl  09:56   0:00 /usr/libexec/colord-sane
anthony   1647  0.0  0.0 465728  4132 ?        Sl   09:56   0:00 /usr/libexec/gsd-printer
anthony   1652  0.0  0.0 242524  5008 ?        Sl   09:56   0:00 /usr/libexec/gvfs-udisks2-volume-monitor
root      1654  0.0  0.0 369780  5168 ?        Ssl  09:56   0:00 /usr/lib/udisks2/udisksd --no-debug
anthony   1660  0.0  0.0 241732  1848 ?        Sl   09:56   0:00 /usr/libexec/gvfs-afc-volume-monitor
anthony   1663  0.0  0.0 167656  2120 ?        S    09:56   0:00 /usr/libexec/gvfs-gphoto2-volume-monitor
anthony   1671  104  2.9 1810676 175632 ?      Sl   09:56  11:52 /usr/bin/gnome-shell
anthony   1680  0.0  0.2 564624 15264 ?        Sl   09:56   0:00 nm-applet
anthony   1681  0.0  0.1 430208 10144 ?        Sl   09:56   0:00 gnome-screensaver
anthony   1684  3.7  0.3 494456 21752 ?        Sl   09:56   0:25 /usr/libexec/tracker-store
anthony   1687  0.0  0.2 552040 14644 ?        Sl   09:56   0:00 /usr/libexec/evolution/3.4/evolution-alarm-notify
anthony   1688  0.0  0.1 420604  8504 ?        Sl   09:56   0:00 zeitgeist-datahub
anthony   1689  0.0  0.0 296100  4352 ?        Sl   09:56   0:00 /usr/libexec/deja-dup/deja-dup-monitor
anthony   1690  3.4  2.9 1198344 178712 ?      SNl  09:56   0:23 /usr/libexec/tracker-miner-fs
anthony   1692  0.0  0.0 112088  1272 ?        S    09:56   0:00 /bin/sh /usr/bin/gnome-do
anthony   1700  0.1  0.5 725800 34788 ?        Sl   09:56   0:00 mono /usr/lib64/gnome-do/Do.exe
anthony   1706  0.0  0.2 266092 16560 ?        S    09:56   0:00 /usr/bin/python /usr/bin/zeitgeist-daemon
anthony   1710  0.0  0.0 255760  2492 ?        Sl   09:56   0:00 /usr/libexec/dconf-service
anthony   1770  0.0  0.2 771404 12468 ?        Sl   09:56   0:00 /usr/libexec/evolution-calendar-factory
anthony   1781  0.0  0.1 333104  6072 ?        Sl   09:56   0:00 /usr/libexec/gnome-shell-calendar-server
anthony   1785  0.0  0.1 342084  6700 ?        Sl   09:56   0:00 /usr/libexec/mission-control-5
anthony   1789  0.0  0.2 415616 13240 ?        Sl   09:56   0:00 /usr/libexec/goa-daemon
anthony   1826  0.1  0.2 393060 15880 ?        Sl   09:56   0:00 /usr/libexec/libsocialweb-core
anthony   1836  0.5  0.2 666768 16892 ?        Sl   09:56   0:03 gnome-terminal
anthony   1842  0.0  0.0   8412   696 ?        S    09:56   0:00 gnome-pty-helper
anthony   1843  0.0  0.0 115644  3336 pts/0    Ss   09:56   0:00 bash
root      1954  0.0  0.0 149232  1732 pts/0    S    09:56   0:00 su
root      1958  0.0  0.0 115652  3352 pts/0    S    09:56   0:00 bash
anthony   2041  6.0  1.8 775676 112584 ?       SLl  09:57   0:39 /opt/google/chrome/chrome       
anthony   2046  0.0  0.1 344568  6216 ?        S    09:57   0:00 /opt/google/chrome/chrome       
anthony   2048  0.0  0.0   6416   288 ?        S    09:57   0:00 /opt/google/chrome/chrome-sandbox /opt/google/chrome/chrome --type=zygot
root      2049  0.0  0.0  27956  1724 ?        S    09:57   0:00 /usr/lib/udev/udevd
anthony   2050  0.0  0.2 363304 16472 ?        S    09:57   0:00 /opt/google/chrome/chrome --type=zygote
root      2051  0.0  0.0      0     0 ?        Z    09:57   0:00 [chrome-sandbox] <defunct>
anthony   2053  0.0  0.0 106592  3812 ?        S    09:57   0:00 /opt/google/chrome/nacl_helper_bootstrap /opt/google/chrome/nacl_helper
anthony   2082  0.0  0.4 957216 27456 ?        Sl   09:57   0:00 /opt/google/chrome/chrome --type=renderer --lang=en-US --force-fieldtest
anthony   2086  1.3  0.8 980324 53604 ?        Sl   09:57   0:08 /opt/google/chrome/chrome --type=renderer --lang=en-US --force-fieldtest
anthony   2090  0.1  0.6 956332 36356 ?        Sl   09:57   0:00 /opt/google/chrome/chrome --type=renderer --lang=en-US --force-fieldtest
anthony   2094  0.0  0.5 951212 32044 ?        Sl   09:57   0:00 /opt/google/chrome/chrome --type=renderer --lang=en-US --force-fieldtest
anthony   2120  1.1  2.2 1095784 137484 ?      Sl   09:57   0:07 /opt/google/chrome/chrome --type=renderer --lang=en-US --force-fieldtest
anthony   2131  0.0  0.6 958800 39868 ?        Sl   09:57   0:00 /opt/google/chrome/chrome --type=renderer --lang=en-US --force-fieldtest
anthony   2139  0.1  0.9 977672 55040 ?        Sl   09:57   0:00 /opt/google/chrome/chrome --type=renderer --lang=en-US --force-fieldtest
anthony   2147  9.0  3.4 1180020 210872 ?      Sl   09:57   0:58 /opt/google/chrome/chrome --type=renderer --lang=en-US --force-fieldtest
anthony   2154  0.6  1.3 1040420 82688 ?       Sl   09:57   0:04 /opt/google/chrome/chrome --type=renderer --lang=en-US --force-fieldtest
anthony   2161  0.2  1.0 986732 63176 ?        Sl   09:57   0:01 /opt/google/chrome/chrome --type=renderer --lang=en-US --force-fieldtest
anthony   2239  0.7  0.5 493920 35708 ?        Sl   09:57   0:04 /opt/google/chrome/chrome --type=plugin --plugin-path=/usr/lib64/flash-p
anthony   3440  0.0  0.3 375940 18544 ?        Sl   10:00   0:00 /opt/google/chrome/chrome --type=plugin --plugin-path=/opt/google/talkpl
anthony   3443  0.0  0.1 396096 11816 ?        Sl   10:00   0:00 /opt/google/talkplugin/GoogleTalkPlugin
root      3502  0.0  0.0      0     0 ?        S    10:01   0:00 [kworker/3:0]
anthony   3513  4.4  2.2 1021952 134732 ?      Sl   10:01   0:16 /opt/google/chrome/chrome --type=renderer --lang=en-US --force-fieldtest
root      3557  0.1  0.0      0     0 ?        S    10:06   0:00 [kworker/3:1]
root      3565  0.0  0.0 106844   504 ?        S    10:07   0:00 sleep 60
root      3570  0.0  0.0 115736  1192 pts/0    R+   10:07   0:00 ps aux



Attached is output of strace of gnome-shell process that has the high CPU: 
strace -p 1671
Comment 1 Mads Kiilerich 2012-04-16 13:12:19 EDT
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.
Comment 2 Owen Taylor 2012-04-20 13:22:01 EDT
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?
Comment 3 Mads Kiilerich 2012-04-23 10:45:07 EDT
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.
Comment 4 Mads Kiilerich 2012-04-23 12:15:49 EDT
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.
Comment 5 Alon Levy 2012-06-05 09:46:38 EDT
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
Comment 6 Ray Strode [halfline] 2012-06-05 10:27:01 EDT
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)
Comment 7 Mads Kiilerich 2012-06-05 10:36:58 EDT
(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.
Comment 8 nickoladze 2012-06-06 02:40:04 EDT
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.
Comment 9 Alon Levy 2012-06-06 04:35:30 EDT
(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.
Comment 10 Alon Levy 2012-06-06 04:37:40 EDT
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
Comment 11 Alon Levy 2012-06-06 10:26:08 EDT
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.
Comment 12 nickoladze 2012-06-06 20:01:49 EDT
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
Comment 13 nickoladze 2012-06-06 20:07:45 EDT
Oops hit submit too soon, here's the output from strace -fcp after a short run http://p.sldr.us/raw/YSnEAiOb
Comment 14 Mads Kiilerich 2012-06-06 20:33:31 EDT
(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.
Comment 15 nickoladze 2012-06-06 20:40:38 EDT
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.
Comment 16 nickoladze 2012-06-08 20:14:15 EDT
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.
Comment 17 Eric Smith 2012-07-10 19:18:38 EDT
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.
Comment 18 Eric Smith 2012-07-11 02:46:00 EDT
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.
Comment 19 Eric Smith 2012-07-11 13:32:08 EDT
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.
Comment 20 nickoladze 2012-07-11 21:43:07 EDT
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.
Comment 21 Eric Smith 2012-07-12 13:02:12 EDT
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.
Comment 22 Martin 2012-09-28 17:27:34 EDT
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
Comment 23 javiermon 2012-10-29 19:29:00 EDT
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
Comment 24 Michel Alexandre Salim 2012-11-04 01:21:20 EST
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.
Comment 25 Kalev Lember 2012-11-13 16:05:07 EST
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.
Comment 26 Michel Alexandre Salim 2012-11-14 00:52:57 EST
(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,
Comment 27 javiermon 2012-11-14 02:35:37 EST
Hi

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

Thanks,
Comment 28 Michel Alexandre Salim 2012-11-16 03:37:15 EST
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.
Comment 29 Juan Jesus Prieto Tapia 2012-11-19 06:49:39 EST
Thanks, javiermon, that solved my problem too!.
Comment 30 Juan Jesus Prieto Tapia 2013-02-01 04:21:46 EST
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.
Comment 31 longint 2013-02-06 13:39:38 EST
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
Comment 32 Mads Kiilerich 2013-02-06 14:11:10 EST
(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.
Comment 33 longint 2013-02-07 15:07:59 EST
Any hints? Funny enough my system is the same as Mads's.

Mads's - did you try with nvidia drivers also?
Comment 34 Mads Kiilerich 2013-02-07 18:43:34 EST
(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.
Comment 35 longint 2013-02-08 04:42:44 EST
(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?
Comment 36 longint 2013-02-11 11:21:56 EST
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...
Comment 37 Joergen Thomsen 2013-03-11 06:22:11 EDT
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
Comment 38 Joergen Thomsen 2013-03-11 06:37:34 EDT
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.
Comment 39 Mads Kiilerich 2013-03-11 06:52:42 EDT
FWIW, with the latest f18 testing updates I don't see the problem on my MacBookPro10,1.
Comment 40 Grosswiler Roger 2013-03-11 12:42:01 EDT
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.
Comment 41 Joergen Thomsen 2013-03-14 18:19:33 EDT
(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)
Comment 42 Oliver Paukstadt 2013-04-11 12:51:28 EDT
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
Comment 43 Gunnar Hellekson 2013-06-29 21:29:21 EDT
See this same behavior in F19 beta. gnome-shell settles down immediately after switching to a text console.
Comment 44 Fedora End Of Life 2013-07-03 21:43:58 EDT
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.
Comment 45 Philip Prindeville 2013-07-04 00:55:21 EDT
I'm seeing this on F18 (updated) running it on Parallels as a VM.
Comment 46 Martin Dengler 2013-07-10 16:56:29 EDT
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).
Comment 47 Joe Doss 2013-07-24 16:51:14 EDT
(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.
Comment 48 davidshumway 2013-08-10 23:01:09 EDT
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.
Comment 49 Alves 2013-11-27 02:20:06 EST
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?
Comment 50 Need Real Name 2013-12-20 01:07:53 EST
I am now seeing this on Fedora 20. I did not have the problem on Fedora 19.
Comment 51 Need Real Name 2014-01-03 16:42:20 EST
Anyone know anything?
Comment 52 Need Real Name 2014-01-03 16:46:02 EST
Seems to be related: https://bugzilla.gnome.org/show_bug.cgi?id=719418
Comment 53 Gerry Reno 2014-02-27 21:55:34 EST
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.
Comment 54 John Hein 2014-02-27 22:20:42 EST
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.
Comment 55 Need Real Name 2014-03-13 19:24:32 EDT
Same problem. Freshly installed Fedora 20 machine.
Comment 56 John Hein 2014-03-13 20:23:08 EDT
In comment 54, of course I meant alt-f2 + r (not alt + r).
Comment 57 ptg 2014-03-28 15:00:27 EDT
I am now having this problem with Fedora 20.  I didn't have it with 17, or 19 (did not try 18).
Comment 58 Marius Andreiana 2014-05-29 03:39:29 EDT
Created attachment 900260 [details]
lspci

Me too, on F20. Happens only when Chrome is open.
Comment 59 William Cohen 2014-05-29 09:56:52 EDT
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`
Comment 60 Marius Andreiana 2014-05-30 05:34:41 EDT
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.
Comment 61 William Cohen 2014-05-30 10:55:01 EDT
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.
Comment 62 Marius Andreiana 2014-05-31 04:18:07 EDT
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
Comment 63 Marius Andreiana 2014-05-31 04:19:43 EDT
Chrome no longer uses CPU constantly after I disabled everything related to GPU in chrome://flags

Thanks
Comment 64 John Hein 2014-06-01 06:41:52 EDT
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.
Comment 65 Cyril Bouteille 2014-08-27 11:47:21 EDT
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
Comment 66 Osamu Nagano 2015-01-20 00:24:55 EST
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
Comment 67 Fedora End Of Life 2015-05-29 04:43:34 EDT
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.
Comment 68 Fedora End Of Life 2015-06-29 07:38:17 EDT
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.
Comment 69 Massimiliano 2015-11-06 18:32:50 EST
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?