When resizing windows running the kwin as composition manager in OpenGL mode, a lot of swap is used and the performance degrades over time. Its a fresh Fedora-13 installation, with an R200 class hardware. Even turning composition off again, doesn't seem to free the memory. The following "free" outputs were with ~30s resizing between each: Swap: 2047992 286732 1761260 Swap: 2047992 687388 1360604 Swap: 2047992 1034560 Swap: 2047992 1254236 793756 Swap: 2047992 1479360 568632 (kwin composition already turned off again) Its disturbing because: - Suspend to disk doesn't work or is very slow, because all the swap is already used. - System performance starts to degrade System-Information: X.Org X Server 1.8.0 Radeon 6.13.0 "ATI Radeon Mobility 9000 (M9) Lf (AGP)" (ChipID = 0x4c66)
Can you see what is using all the memory? Is it kwin? The xserver?
X stays at 24mb RSS, kwin at 28mb RSS. xrestop shows constantly ~30mb of pixmaps allocated. Also the "used" memory stays the same, its only swap thats filling up although there's plenty of free ram available. I remember having the same kind of problem with early intel drivers, after they switched to GEM. Problems were solved when they implemented some "shrinker logic", but to be honest I have no clue what this was all about ;)
(In reply to comment #2) > X stays at 24mb RSS, kwin at 28mb RSS. > xrestop shows constantly ~30mb of pixmaps allocated. > > Also the "used" memory stays the same, its only swap thats filling up although > there's plenty of free ram available. So apparently it's not 'normal' memory leaking. Is the leak reflected in /proc/dri/0/gem_objects ?
Seems to, after resizing a few minutes gem_objects looks like: [ce@cebox ~]$ cat /proc/dri/0/gem_objects 4977 objects -1432866816 object bytes 0 pinned 0 pin bytes 0 gtt bytes 0 gtt total [ce@cebox ~]$ free total used free shared buffers cached Mem: 2061952 2008144 53808 0 528 1454268 -/+ buffers/cache: 553348 1508604 Swap: 2047992 1270176 777816 Disabling composition freed only a few gem_objects and ~100mb swap: [ce@cebox ~]$ cat /proc/dri/0/gem_objects 4272 objects -1451466752 object bytes 0 pinned 0 pin bytes 0 gtt bytes 0 gtt total By the way I am also experiencing problems with windows larger than ~2048px when composition is turned on. Should I file another bug about that?
Something seems to be leaking BOs. Is the leak the same with kwin using direct or indirect rendering? With direct rendering, does the leak recover when killing kwin? In general, does it recover when the X server dies? ...
Only killing X recovers the memory. Killing kwin doesn't help and direct/indirect rendering doesn't make a difference :/
Do you know which commit from server-1.8-branch your X server is based on exactly, and if it has any patches touching glx/ or hw/xfree86/dri2/?
(In reply to comment #4) > By the way I am also experiencing problems with windows larger than ~2048px > when composition is turned on. Should I file another bug about that? The max texture and render target size on r2xx is 2048 pixels. It's a hardware limitation. GL apps should query the max texture size and not exceed it.
Its basically a stock Fedora 13
So another report dies siletly :/
(In reply to comment #10) > So another report dies siletly :/ Clemens, this isn't free entertainment for you. ;) Please help us narrow down why you're seeing this bug while we aren't, e.g. by trying if it also happens with another compositing manager like compiz, or with current upstream components, ... Also, (In reply to comment #9) > Its basically a stock Fedora 13 Is not sufficient information for an upstream report.
Hello I have the same issue. 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200] (rev 01) It has 128Mb RAM onboard. I'm using Gentoo and: linux-2.6.38-r3 xorg-server-1.9.4 libdrm-2.4.25 xf86-video-ati-6.14.1 mesa-7.10.2-r1 (In reply to comment #7) > Do you know which commit from server-1.8-branch your X server is based on > exactly, and if it has any patches touching glx/ or hw/xfree86/dri2/? Seems no. Any extra information? Thanks.
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.