Why is plasma hammering my CPU?

Wed Oct 13 12:03:01 BST 2010

Dotan Cohen posted on Wed, 13 Oct 2010 11:24:44 +0200 as excerpted:

> Why is plasma hammering my CPU? See here:
> 
> top - 11:22:19 up 5 min,  2 users,  load average: 1.30, 0.95, 0.43
> Tasks: 158 total,   2 running, 155 sleeping,   0 stopped,   1 zombie
> Cpu(s): 50.0%us,  7.8%sy,  0.0%ni, 41.6%id,  0.7%wa,  0.0%hi,  0.0%si, 
> 0.0%st Mem:   2055992k total,   950448k used,  1105544k free,    32348k
> buffers Swap:  2931856k total,        0k used,  2931856k free,   312416k
> cached
> 
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  1717 maverick  20   0  766m  72m  33m R   94  3.6   4:57.16
> plasma-desktop
>  1100 root      20   0  140m  16m 5032 S   18  0.8   0:57.15 Xorg 4426
>  maverick  20   0  693m 207m  34m S    6 10.3   0:29.02
> firefox-bin
>  1801 maverick  20   0  9248 1236  828 S    1  0.1   0:01.83
> ksysguardd
>  3640 maverick  20   0  353m  23m  16m S    1  1.2   0:00.90 konsole
>    27 root      20   0     0    0    0 S    0  0.0   0:00.16 ata_sff/0
>    54 root      20   0     0    0    0 S    0  0.0   0:00.36 kondemand/0
> 
> 
>  Might it be a plasmoid? I've disabled them one by one but the
> situation does not improve. This is KDE 4.5.1 on Kubuntu.

Well, I'd not call Kubuntu exactly the most efficient distribution in the 
world, but aside from that...

You've been around for long enough on the kde groups/lists that much of 
this will be rehash, but some of it might be new...

What plasmoids do you actually have running, what are your effects 
settings, what graphics hardware and driver (plus CPU type, cores and 
speed), and what versions of kernel, xorg-server, libdrm, mesa and xorg 
graphics driver are you running?  Also, kms or ums mode?  And is that the 
new 10.10 and the shipped kde with it or an older one and/or newer kde?

Note that if you have real-time updated plasmoids like temp/cpu/netspeed 
meters on the desktop/activity and are running semi-transparent windows, 
especially on lower power GPUs without efficient CPU offloaded 
compositing, plasma-desktop and/or kwin can take rather more CPU than 
expected when translucent windows are overtop the updating plasmoids, and 
rather more than taken if the same plasmoids are on a panel that's either 
hidden or always-on-top or running in a topmost window in the plasmoid-
viewer app.  Pre-kde-4.3.1 (IIRC) this was **REALLY** bad due to a qt bug/
feature that was caught and worked around for that release, then fixed in 
later qt releases, but it can still be an issue on slower hardware without 
that bug.

For comparison, Gentoo/~amd64 with the entire @world recently recompiled 
using gcc 4.5.1, glibc 2.12.1 (gentoo revision -r1), xorg-server 1.9.0.901 
(the first 1.9.1 rc, I believe), mesa 7.9, libdrm 2.4.22, xf86-video-ati 
on a Radeon hd4650, linus kernel 2.6.36-rc7-149 (that's 149 commits past 
rc7, actually plus one locally, a reversion of a troublesome commit I've 
filed a bug on), kde 4.5.2, on a now older dual dual-core Opteron 290 (so 
four cores each @ 2.8 GHz), 6 gig real RAM, no real-time-updating plasmoids 
on the desktop/activity, but with a whole lineup of yasp-scripted plasmoids 
running across the top sixth of a 1920x2160 (2 x 1920x1080, stacked, so 
it's a third of the top monitor) updating mostly every 2 seconds, and with 
fairly high effects, I idle at 8-16% total CPU usage on all four cores, 
with plasma-desktop itself taking the top long-term CPU hog spot at 12.6% 
(of a single core).

Also, KDE 4.5.x is noted for a couple new factors, graphically.  A couple 
of OpenGL 2.0 (I believe) effects are made use of by default, if the X 
driver says it supports them.  Specifically, the blur effect uses one, and 
effects such as inverse use another.  Particularly on xorg/kernel/mesa/
drivers that aren't equally as new as the kde being run, this has caused 
issues for people with certain hardware, where the drivers have claimed to 
support OpenGL features they actually don't (or only support in software 
fallbacks), thus allowing more games (which apparently test for more than 
they actually make use of most of the time) to run, but at the cost, it 
turns out now that desktops are actually trying to use these claimed 
supported features as well, of speed and/or stability when the features 
are actually used in more than a trivial fashion.  From the reports I've 
read, this has seemed to affect those using particular Intel hardware 
(with specific not all of near the same vintage kernel/driver/mesa/xorg 
combos especially) the worst, with certain native xorg Radeon driver users 
(thus not the frglx drivers) also affected.  I'd be in the latter group 
but since I keep my entire system at the leading and sometimes bleeding 
edge, it hasn't affected me that much (tho other problems, like the one I 
mentioned I filed a kernel bug on, have, but that's actually part of the 
fun of testing pre-release software -- as long as it's not like kde-4.3 
and earlier and claiming full release quality before it's even decent beta 
quality, at least; that's simply cruel and unusual punishment deliberately 
inflicted on users by developers who obviously don't particularly care).

So in particular if you're running Intel graphics, or Radeon graphics with 
the xorg-native drivers, and seeing slowdowns, do turn down your effects 
level for kde 4.5.  Well, either that or ensure that you're running the 
latest kernel/xorg/mesa/driver combo, which isn't likely to be the case 
out-of-the-box for non-rolling releases, even brand new ones like kubuntu 
10.10.

And if you're running real-time-updating plasmoids on the desktop, 
consider removing them or placing them on auto-hide or always-on-top 
panels, tho this won't make the difference it did before that particular 
bug was fixed with kde 4.3.1 I believe it was.

Finally, with kde4, a /decent/ video card with good OpenGL support makes a 
HUGE difference.  Upgrading from a Radeon 9200 r2xx series card/chip to a 
Radeon hd4650/rv730 made a HUGE difference to me.  It was an investment 
VERY worth the money, tho unfortunately it wasn't something I could have 
invested in much earlier as the support simply wasn't there, earlier.  (As 
it was, I was running live git drivers for awhile, because there simply 
wasn't a release, even beta, available with OpenGL and KMS support for the 
product yet, when I installed.)

But meanwhile, the r800 series isn't yet well supported, and the kernel 
bug I mentioned may kill certain r600/r700 series OpenGL for those running 
either the 2.6.35.x stable series (tho 2.6.35 itself is fine) or 2.6.36-
rcs, at least for those running rv730s on certain older amd64 AGP based 
hardware like mine.  Hopefully that'll be fixed by release, as the commit 
causing the bug has been long since bisected to and I'm reverting it here, 
but I'm a bit discouraged that the commit not only made it into the 
2.6.35.x stable series as well, but that it has remained around to affect 
others for several stable kernel releases too, ESPECIALLY when that stable 
series fixed a couple well noted security bugs too.  Given that it's a 
stable-tree bug too, I'd have expected a bit more action on the bug than 
I've seen, but oh, well, it's not like us early kde4 users aren't used to 
show-stopping bugs on pre-beta quality products never-the-less released 
and claimed to be ready for ordinary use, I suppose, compared against 
which the kernel folks are positively saintly, even if they do take a 
couple extra stable releases to get a supposedly stable-tree show-stopper 
bug worked out now and again.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.