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

[Philipp Knechtges]

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

(Updated May 21, 2011, 12:53 p.m.)


Review request for kwin and Plasma.


Changes
-------

So now every application which loads libkworkspace uses the 5*pagesize threshold.

Some numbers for plamsa-desktop:
First without patch, directly after startup:
Arena 0:
system bytes     =   22970368
in use bytes     =   22039088
Arena 1:
system bytes     =     135168
in use bytes     =       8704
Arena 2:
system bytes     =     135168
in use bytes     =       8480
Arena 3:
system bytes     =     135168
in use bytes     =       7968
Arena 4:
system bytes     =     135168
in use bytes     =       9472
Total (incl. mmap):
system bytes     =   30732288
in use bytes     =   29294960
max mmap regions =          4
max mmap bytes   =   12984320

After changing theme:
Arena 0:
system bytes     =   34635776
in use bytes     =   25882880
Arena 1:
system bytes     =     135168
in use bytes     =       5568
Arena 2:
system bytes     =     135168
in use bytes     =       8480
Arena 3:
system bytes     =     135168
in use bytes     =       4832
Arena 4:
system bytes     =     135168
in use bytes     =       9472
Total (incl. mmap):
system bytes     =   41164800
in use bytes     =   31899584
max mmap regions =          4
max mmap bytes   =   12984320

The numbers are not that bad as in the case of KWin.
KWin does some deep copies of QImage inside GLTexture::load, which are directly released afterwards.
Plasma is afaik also using a pixmap cache, which starts filling up the unused space pretty fast.

With patch applied after theme change:
Arena 0:
system bytes     =   24952832
in use bytes     =   20124688
Arena 1:
system bytes     =     135168
in use bytes     =       5568
Arena 2:
system bytes     =     135168
in use bytes     =       8480
Arena 3:
system bytes     =     135168
in use bytes     =       4832
Arena 4:
system bytes     =     135168
in use bytes     =       9472
Total (incl. mmap):
system bytes     =   39333888
in use bytes     =   33993424
max mmap regions =         28
max mmap bytes   =   17670144

as said before, the impact on plasma isnt that big as in the case of kwin.


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 
  libs/kworkspace/kworkspace.cpp 5e9afb9 
  libs/kworkspace/kworkspace_p.h 1f0dd3d 

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/20110521/8fa2750e/attachment.htm