| Summary: | kompmgr make X consume 80+% cpu time | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | sunmoon1997 <sunmoon1997> |
| Component: | compositing | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | normal | CC: | adam, kde, linux, m.debruijne |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
sunmoon1997
2005-03-29 12:59:24 UTC
I have the same problem. X will hog my CPU until I finally pkill kompmgr. The system will run fine for another hour or so. Then the cycle repeats and I must kill kompmgr again. I'm sorry, this is my first bug post. I should include additional information. I run X.Org 6.8.2-r1 on my gentoo 2.6.11-r7 kernel with composite and GLX inabled. I run nvidia 1.0.7664. My system is an Athon64 with nVidia 6600GT gfx card. Dunno, maybe we should post this at the gentoo buglist. Just for completeness sake: I have the same problem, slightly different configuration though. - kernel 2.6.12-gentoo-r1 - X.org 6.8.2-r2 - nvidia 7664 - KDE 3.4.1 If this is a Gentoo specific bug, please let me know. I already filed it there as bug #97302. not it's probably not gentoo specific i'd say it's either in X (nvidia, composite, render) or in the fading stuff (tat code seems to be slightly buggy :) jff: try to disable fading completely and tell me if things improve I have turned off fading now. Will keep you posted. Personally I had the feeling it had something to do with a lot of opening and closing programs. The other (very related) thing I'm seeing is that X takes up a lot of memory (together with the processor). Looking at the situation with xrestop shows that there is an unknow process taking up a lot of resources (bitmap caching if I recall correctly). Killing kompmgr removes that process as well. the mem hunger /was/ a bug in the fading - it should be fixed in svn trunk Hi Thomas. Left the machine running for a (short) night. Everything still seems to be working. So I guess you are right. Funny that fading seems to fade away my machine ;-) OK after some more days I can definitely say that turning off fading has improved the situation. I don't get X to use 100% of a CPU anymore, but it still slows down slowly. After two days, X will run at 20-25% making the system unworkable. A killall kompmgr will fix the situation (I can live with it for the time being though). As promissed fading is turned off. Transparency and shadows turned on. you can try out recent svn kwin - maybe i (hopefully ;) fixed the CPU hunger of the fades Doesn't seem to be fixed -- alteast for me (SVN of 2005-07-08). *** Bug 110358 has been marked as a duplicate of this bug. *** So, we have bug reports at freedesktop, gentoo and kde. I think KDE is the right place: https://bugs.gentoo.org/show_bug.cgi?id=96538 https://bugs.freedesktop.org/show_bug.cgi?id=3581 *** This bug has been confirmed by popular vote. *** Just another voice in the crowd saying "I have the same prob and have seen all the behavior described above" For the record I am running an AMD-64 3000 with a gig of ram and a nvidia 6600 GT card. Linux: 2.6.13 Xorg: 6.8.2 kdebase: 3.4.2 I would *love* to see this fixed. I'm running Debian unstable with nVidia 8178, KDE 3.5, and Xorg 6.8.2.dfsg.1-11. The other night I discovered that with these nVidia drivers, translucency and shadows seem stable--I've had X crash twice, which I suspect is related, but I'm not sure. But after leaving the system sitting during the day until I got home, everything was very, very slow: switching apps, loading new apps, and drawing windows. CPU usage was no more than 10%, memory usage was at less than 70%, and swap usage was minimal. During the long waits, there was no CPU activity and no disk activity, everything was just very slow. But after turning translucency/shadows off and back on, everything is moving at normal speed again. Again, CPU usage as reported by the kernel is at idle levels when this happens, same for memory and swap usage, and disk activity. If I can help debug this, please let me know. KDE with X.org has visually surpassed OS X in many ways, it just needs final tuning. By the way, since this happens on Debian also, maybe the platform should be changed. Although, since CPU usage is not high when it happens, maybe it's a separate bug? Hi, I have the same problem, I turned off fade to see what happens. I'm using linux 2.6.12-10 , xorg 2.8.2 and KDE 3.5.2. The distro is Kubuntu breezy. I see this bug dates from a long time, what is the state of it? Thanks Ezequiel as the future's probably on OpenGL through XGl and AIGLX, kompmgr was not intended to be a longtime solution (but just a hack to play with) and the nvidia RenderAccel seems to hate XOrg7.x (so i cannot use it anymore) - consider this concept to be dead for KDE4 -so: won't fix :( Ok, then, I'll wait for XGL. Anyway, I added a button with "killall -9 kcompmgr" just in case. An awfull hack, but should work. the clean way would be to call "dcop kwin default stopKompmgr" there's somewhere a half usefull kicker applet on kde-apps.org i wrote for this purpose |