Summary: | plasma, kwin and Xorg together spontaneously start CPU hogging | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | squan |
Component: | compositing | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alpha_one_x86, aseigo, cyril.baletaud, hsantanna, notmart, roman.karlstetter, sgh, tinchio.nqn |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
sysprof of kwin using 100% cpu
plasma-desktop using 20% cpu |
Description
squan
2009-02-18 22:30:07 UTC
A single other conspicuousness is that the clock plasmaoid shows noon all the time (which can be remidied by changing a clock setting). But I doubt that this is related to the described CPU hogging. perhaps syprof could say something more about the sudden cpu hogging, also try to restart kwin or tremporarly switch to another window manager, to exclude a possible cause seems similar to my problem (https://bugs.kde.org/show_bug.cgi?id=184251), does xorg also uses an importan percentage of CPU? I can confirm this .... The cpu.ohgging stop when issuing a kwin --replace & but then start again after a while. Created attachment 35211 [details]
sysprof of kwin using 100% cpu
Created attachment 35212 [details]
plasma-desktop using 20% cpu
maybe it helps saying that i usse the nvidia driver 185.18.14 since the kwin 100% sysprof is speding much time in libGLcore.185.18.14 I (the reporter) use Intel graphics driver. So this problem is presumable independent of the graphics driver. I'm now using KDE-4.3 betas (from openSUSE factory) with composite effects disabled for severeal weeks and this kind of CPU hogging no longer happens to me. ok ... disabeling composition with CTRL-SHIFT-F12 also stops the cpu-usage of kwin. This is still present in KDE 4.3 rc2 @comment 9: > ok ... disabeling composition with CTRL-SHIFT-F12 also stops the cpu-usage of kwin. This is not what I did say, but may be it can be proven: I've been without composite and desktop effects for several weeks now and without suffering from this problem. So I activated desktop effects again. And again I observe increased and latent CPU activity of the kwin and Xorg and plasma-desktop processes. The difference compared with some weeks ago is that the cumulated load is far below 100%: top reports around 10% for each. At the other commenters: Are you observing 100% CPU load? If I send plasma-desktop a STOP signal CPU activity level stays increased. If I send kwin a STOP signal OR I deactivate composite thenXorg activity goes below 10%. So I would say activating composite makes kwin permanently interact with X (maybe just some pointless event processing) in a way that sets both under significant CPU load. The increased plasma-desktop CPU load is independent from composite and thus should have a completely different cause. It's advisable to deactivate composite when running on battery. That is also what I see. Allthough plasma-desktop seems to be behaving necely in KDE 4.3rc2. Kwin is still a cpu-hog. Actually kwin eating cpu-cycles happenens every time I login, with no exception. Whith kde 4.3 i still happenens. Both on a system with Nvidia drivers and one with intel-drivers. OpenGL compositing usually (actually it depends on driver and GPU, load may be assigned to KWin or X11) loads the CPU on heavy screen updates (like a giant video background...) so you should activate the "Show paint" plugin and watch for fast flickering screen areas. Maybe some plasmoid runs wild and instantly updates (that does not mean there's any visual update - it could just repaint itself over and over again for no reason) As soon as you turn off compositing (or possibly switch to the XRender backend) this would no more be a problem (moving some data in VRAM is fast, cheap and done by the GPU - just textureFromPixmap can kill you - that does not mean the SHM or even fallback conversions would necessarily do any better...) i notice the same problem with kde-4.3.3 xorg-server-1.6.5 an nvidia-drivers-190.42 activating show paint indicates that the whole screen is updated. and yes, switching effect off/on limits screen updates to single areas again. makes it sense to disable plasmoids one by one for testing if some of them is the cause? No. If the entire screen repaints and toggling desktop FX clears the stage you want to test your effects, i.e. disable them all and reactivate them one by one. (There's a /small/ chance that plasma is the culprit as the desktop covers the entire screen and plasma reacts on effect toggling - but it's not very likely) Good candidates are fullscreen FX like - "wobbly windows" - the desktop switchers - the "magic lamp" - the "slide back" effect and - "scale in" (the window switchers are unlikely) My guess: try the wobble thing first ;-) (there's a reported bug) it's the "minimize animation" plugin... how to reproduce: 1. enable the plugin 2. open kmail and configure it to always show in the systray (so it won't close if you press alt+f4 or if you click on kwin's close button (x) 3. hit alt+f4 or click on (x) or click on kmail's systray icon it seems to happen just with kmail (even when embedded into kontact) and disabling the plugin fix the whole screen update. as a side note: with QT_NO_GLIB set to 1 the kwin's cpu usage difference when the problem occurs is less perceptible (from 2-3% to 10-11% instead to 20%+). In combination with the (shown) kmail systray icon i'm even able to generate a reproducable segfault in the minimize animation - i'm gonna look into it tonight just to let you know: - the segfault is an alternative outcome due to an anvient private patch - the magiclamp effect shows the same behaviour - the problem appears to be that the window is minimzed and immediately deleted (probably gets extra closed) and by catching the deletion and removing the window from the animation stack i could fix this for both - i'll sort out my private (unrelated) code changes tonight and come up with a usable patch (if nobody else does) SVN commit 1054144 by luebking: move animation handling to prePaintScreen, avoid multiple hash lookups BUG: 177985 BUG: 184859 catch windows closing during the animation M +42 -29 minimizeanimation.cpp M +1 -0 minimizeanimation.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1054144 SVN commit 1054146 by luebking: BUG: 177985 BUG: 184859 catch windows closing during the animation M +5 -0 magiclamp.cpp M +1 -0 magiclamp.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1054146 *** Bug 217785 has been marked as a duplicate of this bug. *** *** Bug 218045 has been marked as a duplicate of this bug. *** *** Bug 206910 has been marked as a duplicate of this bug. *** *** Bug 179851 has been marked as a duplicate of this bug. *** |