Review Request: Fixing massive memory consumption in KWin using the raster graphicssystem.

[Commit Hook]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101385/#review4204
-----------------------------------------------------------


This review has been submitted with commit d8949d77b5bc33d540dc7f791cee3691ee9dbb85 by Philipp Knechtges to branch master.

- 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 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
> -----
> 
>   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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20110627/06231740/attachment.htm