gnome-shell high cpu usage

[javiermon]

Hi

A recent update has bump the cpu usage (80-90%) of gnome-shell all the time, even on idle. I think this has happened 2 days ago. I noticed because the cursor is continuosly blinking... any ideas? I'm on intel hw.

checking the logs (/var/log/yum.log) I see no update to gnome-shell, the most probable are some mesa related updates. Anyone else noticed something similar?

thanks,

[brianblaze]

for fun check

sudo cat /var/log/secure

See if anyone has broken into your linux box and is doing evil things with it. Maybe you installed a new service that is always running now?

When you do HTOP what do you see that is taking up all the cpu%?

[javiermon]

Originally Posted by brianblaze

for fun check

sudo cat /var/log/secure

See if anyone has broken into your linux box and is doing evil things with it. Maybe you installed a new service that is always running now?

When you do HTOP what do you see that is taking up all the cpu%?

Hi

Thanks for the answer, but no, nobody has broken into my linux box...
This is a consecuence of a package upgrade, I understand F18 is still under heavy development, but before filling a but report I would like to know if anyone is experiencing the same. top & htop report high cpu usage of gnome-shell as described in my post.

[brianblaze]

Well on my 18 my cpu usage is almost 0% and what service or process is taking up all that cpu % I didn't see you write that anywhere...

[javiermon]

Originally Posted by brianblaze

Well on my 18 my cpu usage is almost 0% and what service or process is taking up all that cpu % I didn't see you write that anywhere...

gnome-shell process, are you up to date? which hw do you use?

After trying to downgrade the kernel a couple of times and coming back to lastest @update-testing kernel the issue has dissapeared... not sure what has happened or changed (since I'm using the same kernel as before), but now gnome-shell is working fine. weird

---------- Post added at 11:37 PM ---------- Previous post was at 10:03 PM ----------

It's back again... 80% cpu usage...

[brianblaze]

very weird but I am running 18 on a VMWARE VM and it's updated and such

[nonamedotc]

There was this bug in F17 - https://bugzilla.redhat.com/show_bug.cgi?id=812624 - which is still open. Perhaps related?

Well, this is the only one I can find in bugzilla. Perhaps, you could file a bug against F18?

[AdamW]

What graphics card and driver?

[javiermon]

Originally Posted by AdamW

What graphics card and driver?

I'm using intel hd 4000 (ivy bridge) in a hp spectre xt. Using lastest xorg-x11-drv-intel.
I've been searching fedora bugzilla and I think the bug could be https://bugzilla.redhat.com/show_bug.cgi?id=812624 (as nonamedotc says)

I've recreated the directories mentioned in that bug and I no longer have the inotify traces in strace output but the 100 cpu issue is still there. I've tested with older kernels but same issue. I didn't have this problem last week (started on the 28th aprox).

I've also managed to get gnome-shell out of the 100 cpu state by stopping gdm (systemctl stop gdm.service), relaunching it, logging again and no 100%, but not really sure why or if it will persist across reboots (which I don't think it would).

Is there any way to get a more reliable log/trace from gnome-shell? Running it from another maching with gdm is not really an option as I don't have more HW available right now.

[kalev]

You are probably hit by https://bugzilla.redhat.com/show_bug.cgi?id=870695 and using the fallback llvmpipe renderer, which is causing the high cpu usage. Try downgrading to plymouth-0.8.7-1.fc18 to see if that's the issue.

[DBelton]

If it's using llvmpipe, then that's probably the problem. I certainly wouldn't recommend anything using llvmpipe.

You have a few cases where Gnome tries to use llvmpipe.

1: Older hardware. Chances are, if you have graphics hardware old enough to require llvmpipe, then you also have an older CPU that can't handle the load llvmpipe puts on it to render graphics.

2: New hardware that don't have drivers yet. This one is becoming fairly rare, especially on the NVidia side of the graphics adapters. And if you spend the money on new hardware, you want to be able too use it as intended instead of your CPU rendering your graphics.

3: Embedded system, like ARM. This one is about the same as #1. ARM systems may not have the graphics hardware, but they are also limited in CPU firepower. So, once again, software graphics rendering is useless.

4: Multi-seat. A lot of the multi-seat adapters only support 2D, so they would be forced to use llvmpipe in Gnome as well. Can you imagine what that is going to be like of you get several multi-seat users on one CPU?

I believe that instead of forcing llvmpipe upon users that for some reason or other can't run with hardware OpenGL rendering, they should have a choice, like in KDE. Give them a choice of turning off all of the bells and whistles, using Xrender (which works pretty well), or in the case of Gnome (at least for now) going to fallback mode. I say at least for now, because they are looking to remove fallback mode completely.

My opinion?? Llvmpipe is a piece of garbage for using to render your desktop environment. It's useful for applications that don't run all of the time, but for a desktop, it's useless in it's current state.

[brianblaze]

Originally Posted by DBelton

If it's using llvmpipe, then that's probably the problem. I certainly wouldn't recommend anything using llvmpipe.

You have a few cases where Gnome tries to use llvmpipe.

1: Older hardware. Chances are, if you have graphics hardware old enough to require llvmpipe, then you also have an older CPU that can't handle the load llvmpipe puts on it to render graphics.

2: New hardware that don't have drivers yet. This one is becoming fairly rare, especially on the NVidia side of the graphics adapters. And if you spend the money on new hardware, you want to be able too use it as intended instead of your CPU rendering your graphics.

3: Embedded system, like ARM. This one is about the same as #1. ARM systems may not have the graphics hardware, but they are also limited in CPU firepower. So, once again, software graphics rendering is useless.

4: Multi-seat. A lot of the multi-seat adapters only support 2D, so they would be forced to use llvmpipe in Gnome as well. Can you imagine what that is going to be like of you get several multi-seat users on one CPU?

I believe that instead of forcing llvmpipe upon users that for some reason or other can't run with hardware OpenGL rendering, they should have a choice, like in KDE. Give them a choice of turning off all of the bells and whistles, using Xrender (which works pretty well), or in the case of Gnome (at least for now) going to fallback mode. I say at least for now, because they are looking to remove fallback mode completely.

My opinion?? Llvmpipe is a piece of garbage for using to render your desktop environment. It's useful for applications that don't run all of the time, but for a desktop, it's useless in it's current state.

I learned something new today thanks

[javiermon]

Originally Posted by kalev

You are probably hit by https://bugzilla.redhat.com/show_bug.cgi?id=870695 and using the fallback llvmpipe renderer, which is causing the high cpu usage. Try downgrading to plymouth-0.8.7-1.fc18 to see if that's the issue.

Thanks! cannot downgrade (broken dependencies) but make sense, given that if I restart gdm the bug vanishes.

[kalev]

Try:

yum downgrade 'plymouth*'

[javiermon]

Originally Posted by kalev

Try:

yum downgrade 'plymouth*'

That's what i've tried before and with --skip-broken.

sudo yum downgrade plymouth --skip-broken
[sudo] password for javier:
Complementos cargados:langpacks, presto, refresh-packagekit, remove-with-leaves,
: show-leaves
Resolviendo dependencias
--> Ejecutando prueba de transacción
---> Paquete plymouth.x86_64 0:0.8.7-1.fc18 debe ser una desactualización
---> Paquete plymouth.x86_64 0:0.8.8-1.fc18 debe ser eliminado

Paquetes ignorados por problemas de dependencias:
plymouth-0.8.7-1.fc18.x86_64 de fedora
policycoreutils-restorecond-2.1.13-17.fc18.x86_64 es uin duplicado con policycoreutils-restorecond-2.1.13-7.fc18.x86_64