--===============0435636140== Content-Type: multipart/alternative; boundary="===============4957232406563686516==" --===============4957232406563686516== 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/ ----------------------------------------------------------- (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 thre= shold. Some numbers for plamsa-desktop: First without patch, directly after startup: Arena 0: system bytes =3D 22970368 in use bytes =3D 22039088 Arena 1: system bytes =3D 135168 in use bytes =3D 8704 Arena 2: system bytes =3D 135168 in use bytes =3D 8480 Arena 3: system bytes =3D 135168 in use bytes =3D 7968 Arena 4: system bytes =3D 135168 in use bytes =3D 9472 Total (incl. mmap): system bytes =3D 30732288 in use bytes =3D 29294960 max mmap regions =3D 4 max mmap bytes =3D 12984320 After changing theme: Arena 0: system bytes =3D 34635776 in use bytes =3D 25882880 Arena 1: system bytes =3D 135168 in use bytes =3D 5568 Arena 2: system bytes =3D 135168 in use bytes =3D 8480 Arena 3: system bytes =3D 135168 in use bytes =3D 4832 Arena 4: system bytes =3D 135168 in use bytes =3D 9472 Total (incl. mmap): system bytes =3D 41164800 in use bytes =3D 31899584 max mmap regions =3D 4 max mmap bytes =3D 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 dire= ctly released afterwards. Plasma is afaik also using a pixmap cache, which starts filling up the unus= ed space pretty fast. With patch applied after theme change: Arena 0: system bytes =3D 24952832 in use bytes =3D 20124688 Arena 1: system bytes =3D 135168 in use bytes =3D 5568 Arena 2: system bytes =3D 135168 in use bytes =3D 8480 Arena 3: system bytes =3D 135168 in use bytes =3D 4832 Arena 4: system bytes =3D 135168 in use bytes =3D 9472 Total (incl. mmap): system bytes =3D 39333888 in use bytes =3D 33993424 max mmap regions =3D 28 max mmap bytes =3D 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 usag= e 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 prop= erly released pixmaps. But calling malloc_stats() sheds some more light on the subject (non-compos= iting 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 KWi= n uses only less than 10 MB. The problem is that glibc only resizes the heap if the heap has more than 1= 28 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 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=C3=A4=C3=9Flin had some concerns about the portability? Thanks, Philipp --===============4957232406563686516== 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/

Review request for kwin and Plasma.
By Philipp Knechtges.

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

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     =3D   22970368
in use bytes     =3D   22039088
Arena 1:
system bytes     =3D     135168
in use bytes     =3D       8704
Arena 2:
system bytes     =3D     135168
in use bytes     =3D       8480
Arena 3:
system bytes     =3D     135168
in use bytes     =3D       7968
Arena 4:
system bytes     =3D     135168
in use bytes     =3D       9472
Total (incl. mmap):
system bytes     =3D   30732288
in use bytes     =3D   29294960
max mmap regions =3D          4
max mmap bytes   =3D   12984320

After changing theme:
Arena 0:
system bytes     =3D   34635776
in use bytes     =3D   25882880
Arena 1:
system bytes     =3D     135168
in use bytes     =3D       5568
Arena 2:
system bytes     =3D     135168
in use bytes     =3D       8480
Arena 3:
system bytes     =3D     135168
in use bytes     =3D       4832
Arena 4:
system bytes     =3D     135168
in use bytes     =3D       9472
Total (incl. mmap):
system bytes     =3D   41164800
in use bytes     =3D   31899584
max mmap regions =3D          4
max mmap bytes   =3D   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 dire=
ctly released afterwards.
Plasma is afaik also using a pixmap cache, which starts filling up the unus=
ed space pretty fast.

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

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

Descripti= on 

The intention of this patch is to lower the heap fragmentati=
on 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 usag=
e 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 prop=
erly released pixmaps.
But calling malloc_stats() sheds some more light on the subject (non-compos=
iting 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 KWi=
n uses only less than 10 MB.
The problem is that glibc only resizes the heap if the heap has more than 1=
28 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 the=
 sbrk syscall more often. But this should
not be a bottleneck.

Testing <= /h1> 
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?

Diffs= (updated)

  • ConfigureChecks.cmake (e8b64a2)
  • config-workspace.h.cmake (fabe7fa)<= /li>
  • libs/kworkspace/kworkspace.cpp (5e9afb9)
  • libs/kworkspace/kworkspace_p.h (1f0dd3d)

View Diff
--===============4957232406563686516==-- --===============0435636140== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel --===============0435636140==--