This is an automatically generated e-mail. To reply, visit: http://git.revie= wboard.kde.org/r/101385/

This revie=
w has been submitted with commit d8949d77b5bc33d540dc7f791cee3691ee9dbb85 b=
y Philipp Knechtges to branch master.

- Commit

On June 26th, 2011, 1:27 p.m., Philipp Knechtges wrote:

Review request for kwin and Plasma.

By Philipp Knechtges.

Updated June 26, 2011, 1:27 p.m.

Descripti= on

The intention of this patch is to lower the heap fragmentati=
on in KWin when using the raster backend.

One can illustrate the issue with the following testcase: If one currently =
uses the raster backend and
switches back to non-compositing mode one gets easily a similar memory usag=
e like the following:

Situation: 14 windows, QtCurve
KWin started with compositing: 40 MB
KWin switched to non-compositing : more than 70 MB

The first guess might be, that this is due to a memleak because of not prop=
erly released pixmaps.
But calling malloc_stats() sheds some more light on the subject (non-compos=
iting mode):

Arena 0:
system bytes     =3D   72232960
in use bytes     =3D    8180512
Arena 1:
system bytes     =3D     135168
in use bytes     =3D       4784
Total (incl. mmap):
system bytes     =3D   73080832
in use bytes     =3D    8898000
max mmap regions =3D         13
max mmap bytes   =3D   36343808

In other words, the glibc has allocated more than 70 MB memory although KWi=
n uses only less than 10 MB.
The problem is that glibc only resizes the heap if the heap has more than 1=
28 KB of free space at the end, but
many decoration pixmaps are smaller. Using mallopt to tune the threshold to=
 20 KB (i'm open for other suggestions?)
fixes the issue. After the patch:

KWin in compositing mode: 19 MB
KWin switched to non-compositing: 13 MB


Arena 0:
system bytes     =3D   12374016
in use bytes     =3D    6894544
Arena 1:
system bytes     =3D     135168
in use bytes     =3D       4784
Total (incl. mmap):
system bytes     =3D   13750272
in use bytes     =3D    8140416
max mmap regions =3D         67
max mmap bytes   =3D   99463168

Are there some negative effects?
The only negative effect i am aware of is, that Glibc free() is calling the=
 sbrk syscall more often. But this should
not be a bottleneck.

Testing <= /h1>

Tested using a standard Fedora 14.
Would be nice to know, whether other OSes have similar issues?
Martin Gr=C3=A4=C3=9Flin had some concerns about the portability?

Diffs=

ConfigureChecks.cmake (e8b64a2)
config-workspace.h.cmake (fabe7fa)<= /li>
kwin/main.cpp (f767f54)
libs/kworkspace/kworkspace.h (f24ea42)
libs/kworkspace/kworkspace.cpp (5e9afb9)

View Diff

Descripti= on

Testing <= /h1> Tested using a standard Fedora 14. Would be nice to know, whether other OSes have similar issues? Martin Gr=C3=A4=C3=9Flin had some concerns about the portability?

Diffs=

Testing <= /h1>

Tested using a standard Fedora 14. Would be nice to know, whether other OSes have similar issues? Martin Gr=C3=A4=C3=9Flin had some concerns about the portability?