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.
