Bug 28227

Summary: Window-Resize with kwin composition leads to huge amounts of swap used
Product: xorg Reporter: Clemens Eisserer <linuxhippy>
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED INVALID QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Clemens Eisserer 2010-05-24 04:08:22 UTC
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)
Comment 1 Alex Deucher 2010-05-24 08:16:04 UTC
Can you see what is using all the memory?  Is it kwin?  The xserver?
Comment 2 Clemens Eisserer 2010-05-24 08:23:38 UTC
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 ;)
Comment 3 Michel Dänzer 2010-05-25 00:56:27 UTC
(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 ?
Comment 4 Clemens Eisserer 2010-05-25 02:45:46 UTC
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?
Comment 5 Michel Dänzer 2010-05-25 03:58:22 UTC
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? ...
Comment 6 Clemens Eisserer 2010-05-25 05:00:45 UTC
Only killing X recovers the memory.
Killing kwin doesn't help and direct/indirect rendering doesn't make a difference :/
Comment 7 Michel Dänzer 2010-05-25 06:46:32 UTC
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/?
Comment 8 Alex Deucher 2010-05-25 07:57:41 UTC
(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.
Comment 9 Clemens Eisserer 2010-05-28 13:06:25 UTC
Its basically a stock Fedora 13
Comment 10 Clemens Eisserer 2010-06-15 06:58:45 UTC
So another report dies siletly :/
Comment 11 Michel Dänzer 2010-06-15 07:05:56 UTC
(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.
Comment 12 Andrey Batyiev 2011-06-21 15:50:12 UTC
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.
Comment 13 Adam Jackson 2018-06-12 19:08:31 UTC
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.