[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: Review Request: Fixing massive memory consumption in KWin using
From:       "Philipp Knechtges" <philipp-dev () knechtges ! com>
Date:       2011-05-21 12:53:29
Message-ID: 20110521125329.976.90230 () vidsolbach ! de
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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


[Attachment #5 (text/html)]

<html>
 <body>
  <div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
   <table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 \
solid;">  <tr>
     <td>
      This is an automatically generated e-mail. To reply, visit:
      <a href="http://git.reviewboard.kde.org/r/101385/">http://git.reviewboard.kde.org/r/101385/</a>
  </td>
    </tr>
   </table>
   <br />


<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" \
style="background-image: \
url('http://git.reviewboard.kde.org/media/rb/images/review_request_box_top_bg.png'); \
background-position: left top; background-repeat: repeat-x; border: 1px black \
solid;">  <tr>
  <td>

<div>Review request for kwin and Plasma.</div>
<div>By Philipp Knechtges.</div>


<p style="color: grey;"><i>Updated May 21, 2011, 12:53 p.m.</i></p>



<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Changes</h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: \
1px solid #b8b5a0">  <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">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.
</pre>
  </td>
 </tr>
</table>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: \
1px solid #b8b5a0">  <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">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&#39;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.</pre>
  </td>
 </tr>
</table>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: \
1px solid #b8b5a0">  <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">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?</pre>  </td>
 </tr>
</table>




<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> \
(updated)</h1> <ul style="margin-left: 3em; padding-left: 0;">

 <li>ConfigureChecks.cmake <span style="color: grey">(e8b64a2)</span></li>

 <li>config-workspace.h.cmake <span style="color: grey">(fabe7fa)</span></li>

 <li>libs/kworkspace/kworkspace.cpp <span style="color: grey">(5e9afb9)</span></li>

 <li>libs/kworkspace/kworkspace_p.h <span style="color: grey">(1f0dd3d)</span></li>

</ul>

<p><a href="http://git.reviewboard.kde.org/r/101385/diff/" style="margin-left: \
3em;">View Diff</a></p>




  </td>
 </tr>
</table>




  </div>
 </body>
</html>



_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic