--===============2020677695589426570== Content-Type: multipart/alternative; boundary="===============4450342714003361479==" --===============4450342714003361479== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101385/#review5777 ----------------------------------------------------------- This review has been submitted with commit 66b2cc4d31e380e3b2bc7e47477029fc= 39fb7ac7 by Philipp Knechtges to branch KDE/4.7. - Commit On June 26, 2011, 1:27 p.m., Philipp Knechtges wrote: > = > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101385/ > ----------------------------------------------------------- > = > (Updated June 26, 2011, 1:27 p.m.) > = > = > Review request for kwin and Plasma. > = > = > Summary > ------- > = > The intention of this patch is to lower the heap fragmentation in KWin wh= en using the raster backend. > = > One can illustrate the issue with the following testcase: If one currentl= y uses the raster backend and > switches back to non-compositing mode one gets easily a similar memory us= age 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 pr= operly released pixmaps. > But calling malloc_stats() sheds some more light on the subject (non-comp= ositing 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 K= Win uses only less than 10 MB. > The problem is that glibc only resizes the heap if the heap has more than= 128 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 t= he sbrk syscall more often. But this should > not be a bottleneck. > = > = > Diffs > ----- > = > ConfigureChecks.cmake e8b64a2 = > config-workspace.h.cmake fabe7fa = > kwin/main.cpp f767f54 = > libs/kworkspace/kworkspace.h f24ea42 = > libs/kworkspace/kworkspace.cpp 5e9afb9 = > = > Diff: http://git.reviewboard.kde.org/r/101385/diff > = > = > Testing > ------- > = > 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? > = > = > Thanks, > = > Philipp > = > --===============4450342714003361479== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
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 66b2cc4d31e380e3b2bc7e47477029fc39fb7ac7 b= y Philipp Knechtges to branch KDE/4.7.
- 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
Testing <= /h1>
Diffs=
|