Version: unspecified (using KDE 4.7.0) OS: Linux Either right from the login, or very shortly after, kwin hits 100% cpu usage, and that is where it stays. It happens every time. I don't really know what the cause is, so I'll provide as much detail as possible below. This is the results with a fresh ~/.kde4 settings directory, doing little more than staring at the desktop. Reproducible: Always Steps to Reproduce: Log in. Actual Results: Kwin uses 100% CPU on one virtual cpu. Expected Results: Not eating massive amounts of CPU? linux 3.0 nvidia 280.13 kde 4.7.0 qt 4.7.3 I'm using multihead - 4 separate X screens (Good to see support for this back after having been gone since KDE 3.5. Unfortunate that it's a bit buggy though. More bug reports shall follow (: ) This seems to mean 4 instances of kwin. This means 4 Virtual CPUs are being given a 100% load.
a) compositing related? (press SHIFT+Alt+F12 to suspend) b) if (a); run "kcmshell4 kwincompositing", activate the "show paint" plugin. -> got heavy flicker? c) else install & run sysprof (online kernel level profiler) and attach the stats for inspection.
I've changed quite a lot of settings since yesterday and it seems to have conveniently vanished. It doesn't seem to be effects related. I'll revert as many settings as possible and see if I can't find the specific cause when I get a bit of free time. (Monday, perhaps)
Created attachment 63133 [details] sysprof profile
KWin or rather Qt spends all time in event processing -> ::select() -> inotify_poll ... a) could you bisect the cuplrit? (ie. what setting caused this) b) if you can somehow reproduce this, please start kwin from konsole and watch out for "QSocketNotifier: Invalid socket..." messages My understanding is that this only happens if you run 4 X11 servers and KWin instances a once?
Well, I'm not really sure if that's the only case where it can happen, except I don't remember it happening before? (If it did, it would have been less noticeable, seeing as it would have been using 1/4 the cpu time right?) What is inotify_poll and what does it do? (Perhaps this could give me a way to narrow down where to start looking)
kernel function (inotify sends filesystem events - easily spoken ;-) and implementation detail in this regard, i assume. The problem is the high load in the calling "std::select" what means that the process is waiting to perform I/O on a file handle (in this very case being a unix socket) - it's very likely some race condition. That's why it's important to figure. HOWEVER: calling "kwin --replace" occasionally keeps the old process as zombie here, consuming the CPU. I gdb attached into it and it indeed was in event processing. It's likely the very same issue but this process should not exist at all. I think i even googled up an upstream Heisenbug reported to Qt regarding this where the sample code invoked the filesystemwatcher (but cannot recall the url) => can you ensure that the cpu consuming kwin processes are NO bodies but actually the running windowmanager processes? --- devnote: this time it's the unixdipatcher ;-)
I think I caught the whoosh as you flew right over my head :S Translation?
Sorry :) Ok, the important part for you is to check whether the CPU consuming kwin process is really important and not just some leftover. Simply kill it - if it's really important, the windows on one screen will loose their decorations (you'll have to restart kwin on that screen in this case) ---------------- Now the tricky part/s? "inotify" is part of the linux kernel (the thing that talks directly to the hardware and acts as some kind of broker between HW and SW) It informs about file (state) changes, so the Software doesn't have to look at the file all the time whether sth. has changed. The stuff about std::select (in this case, the function is very generic and fundamental) meant that KWin (but that's general Qt functionality) waits to be able to.... errm... look into a messagebox where errr.. the system puts messages whenever something interesting happens (or sometimes to put an answer there) When developing on kwin you often have to restart it. For convenience, the new new process can kill the old client as very first action (--replace, because you cannot have two WMs at the same time) This recently somehow failed and i was left with the old kwin process which did no more manage windows, but took all cpu for looking into that messagebox and dealing with the messages there. I figured that using "gdb" - a program for debugging running applications (you can watch what the program currently does - do NOT attempt to gdb attach to an active kwin process - at least not from the same terminal - VT1 would be ok ;-) A Heisenbug refers to Werner Heisenberg and is called lilke this because of: http://en.wikipedia.org/wiki/Uncertainty_principle
Now, I should probably do it again just to be sure (which involves reproducing the bug first, unfortunately), but I believe I did just that. The decorations disappeared when I killed the kwins; however, the kwin processes didn't really die - they were zombies - and still munching on my computer's brains! I did fluxbox --replace, but if I remember right, shortly after that X crashed. (No, this isn't a regular happening) Anyhow, at that point, no X running, but the kwin processes were still lurking around , eating CPU, and waiting for me to killall -9 them.
We haven't heard of those zombie processes for quite some time, so I assume the bug to be fixed. In case it still happens please reopen.