----------------------------------------------------------- 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. Changes ------- Incorporated Aaron's suggestions of making the function call explicit and the pagesize var const. So far I have only added the trimMalloc call to kwin. The plasma people should decide themselves whether this is necessary for plasma. Summary ------- The intention of this patch is to lower the heap fragmentation 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 usage 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 properly released pixmaps. But calling malloc_stats() sheds some more light on the subject (non-compositing mode): Arena 0: system bytes = 72232960 in use bytes = 8180512 Arena 1: system bytes = 135168 in use bytes = 4784 Total (incl. mmap): system bytes = 73080832 in use bytes = 8898000 max mmap regions = 13 max mmap bytes = 36343808 In other words, the glibc has allocated more than 70 MB memory although KWin 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 = 12374016 in use bytes = 6894544 Arena 1: system bytes = 135168 in use bytes = 4784 Total (incl. mmap): system bytes = 13750272 in use bytes = 8140416 max mmap regions = 67 max mmap bytes = 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. Diffs (updated) ----- 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äßlin had some concerns about the portability? Thanks, Philipp
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
