View Single Post
Old 09-10-08, 10:44 AM   #4
Registered User
Join Date: Dec 2004
Posts: 74
Default Re: 177.xx: Enabling kwin composition leaks memory.

You are not alone, see this thread for proof of other sufferers:
I also experience this problem however I'm not sure if it is nvidia at fault (for once...), it *could* be kwin or something, but given the lack of complains from others on kde forums and what not and nvidia's past history (black windows bug is strikingly reminiscent), it's probable.

Environment info:
177 drivers on intrepid ibex ubuntu amd64 on an x2 3800 amd proc wtih an 8800 gts and 320mB of mem, settings in use are currently with compositing disabled though I did start up x with it on. IPP=1 and GlyphCache seems irrelevant as I've tried both. I don't know how 173 faired with kde 4.1 but its only been recently with 173 that compiz played nice enough together and I could have week+ uptime again or the first time in years. Side note: friend has a similar setup with 7900 gt and my laptop running fedora rawhide with same configurations fitted to a t61p quadro 570m with 512mB of ram. All machines illustrate the same behaviors though. Seems to be worsened with with IPP=2 and any combination of the other xorg options in the performance thread manifesting as significantly many more pauses of which seem longer (15 seconds), more frequent, and start happening in only a few hours after a clean start.

The box I'm reporting on is my main machine and I usually start seeing symptoms at the end of a full day of use but really start feeling them the second, seems like the problem might even happen when the computer is not being used (and no screen saver, just blank screen).

Things run great for at least the first few hours of normal usage and then they start to drag. Particularly annoying is that I use mplayer in full screen alot with vo=xv. Also sometimes I accidentally hit maximize on random normal applications or page to another desktop - I run my dell 3007-hfc monitor at 2560x1600 though and while normally these things are no problem, when whatever resources get low because of this bug, x pauses and goes to 100% and said programs usually become unusably slow to work with when x comes back though x doesn't kill said processes and oom is never ran. Said processes become usable again when resized to a window small enough where the "small enough" seems to vary with how much of the mystery resource is available and thus needs smaller and smaller windows over time. X coming back can take almost a minute sometimes and I have nearly a gigabyte of memory free with 500 in phys though at start time I have 1 gig free of phys and 1 of swap, I mention this as it used to be my normal load minus cache (so no this is not about cache filling up ram otherwise unused ram). At time of writing, x has 676 virtual and 366 resident... I don't have that much stuff opened and nothing really interesting (no opengl) but I don't know whats normal for x anymore. Everything but firefox is laughably incomparible and even closing ff, I bet I'll be back up to full swap and nearly full phys tomorrow (if you couldn't tell, this isn't my first cycle through this) . Total memory usage is 1468/2008MB phys and 497/1027MB swap at this moment. Additionally this doesn't appear to have anything to do with paging and swap as my leds light up solid when my hd is accessed and nothing happens during this pausing period + no hd write/read noise. I've confirmed x taking 100% of a cpu at 2ghz during this pausing period through ssh, nothing else seems obvious at these times. X Idle cpu usage is fairly normal at only about 17% at 1ghz mode (I run with ondemand cpufreq) which it is returning to atm when i don't do *anything*.

On the more annoying side is that audio stuttering spanning multiple SECONDS happens when I do trivial operations involving windows - alt-tabbing (with the simple tabber), creating and closing after and including the second day. Sometimes even on simpler stuff like scrolling. This is probably because I use pulseaudio and despite its -11 niceness, when x goes berserk from said bug pulseaudio gets no cpu time to write new samples reliably, this is really annoying and when combined the other pauses is incredibly frustrating. Otoh I have only one x process and two cores and a context switch just doesn't take that long.... so I guess I'm clueless whats going on there, chrt to rr doesn't seem to change squat.

On the cheap hacks side of things, I've found that disabling compositing and reenabling within session forces a garbage collection of sorts and while eventually fails to do anything, will allow things to function for a while longer (the time the fix is good for decreases each time used but allows apps to fullscreen/maximize again and operate at normal speeds). The pauses still run rampant though. Also, this time around I started with compositing on but disabled it before things started getting bad and I'm still having same problems... perhaps I laid the seeds for this behavior by having it on in the first place though. Also, by stoping kdm and removing & reloading the nvidia module and starting back up, things seem to be ok for a while with seemingly all memory reclaimed but audio pauses seem to either start happening sooner or audio is just screwed because I get audio pauses at the same rates as when the system is taxed and forcing me to take it down for sanity. I don't think everythings as bad as when I have to restart x though but I don't do it often enough to give a completely accurate account.

Attached is a bug report for supporting info.

This bug has me rebooting every few days though and I greatly dislike losing my session and the lack of stability so whoever helps make a fix, you have my thanks.
</huge post>
Attached Files
File Type: gz nvidia-bug-report.log.gz (29.5 KB, 121 views)
nevion is offline   Reply With Quote