Re: Review Request: Fixing massive memory consumption in KWin using the raster graphicssystem.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101385/#review5777 --- This review has been submitted with commit 66b2cc4d31e380e3b2bc7e47477029fc39fb7ac7 by Philipp Knechtges to branch KDE/4.7. - 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 > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fixing massive memory consumption in KWin using the raster graphicssystem.
--- 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 > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fixing massive memory consumption in KWin using the raster graphicssystem.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101385/#review4197 --- Ship it! looks good; let's try it out for 4.8 and now that master is open again for such commits, please push to master at your convenience. - Aaron J. 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 > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fixing massive memory consumption in KWin using the raster graphicssystem.
--- 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
Re: Review Request: Fixing massive memory consumption in KWin using the raster graphicssystem.
--- 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 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fixing massive memory consumption in KWin using the raster graphicssystem.
> On May 19, 2011, 7:34 a.m., Aaron J. Seigo wrote: > > those are some impressive results. my guess is that we likely have a very > > similar issue in plasma. in both cases, we are dealing with lots of small > > bits of memory in the form of pixmaps, strings, etc. that are fairly > > constantly coming and going. switching between compositing and no > > compositing is probably the 'worst case' real world scenario for this. > > > > if this does test out well, i'd suggest putting this code in libkworkspace > > so that all of our apps with this usage pattern (plasma-desktop, > > plasma-netbook, krunner, kwin, ..) can take advantage of a common > > implementation. a set of static methods in the KWorkspace namespace should > > suffice. > > > > if you could repeat your experiment with plasma-desktop with and without > > such a patch, that would be great and let us know whether we should adopt > > such a strategy across the plasma shell components. > > > > as for portability ... i'm not overly concerned about the portability of > > this to non-glibc systems as those systems are our primary targets. > > however, instead of checking for GLIBC the code could simply check for > > M_TRIM_THRESHOLD. for comparison, here is how busybox does this same trick > > for both the trim size and mmap request size threshold: > > > > #ifndef PAGE_SIZE > > # define PAGE_SIZE (4*1024) /* guess */ > > #endif > > #ifdef M_TRIM_THRESHOLD > > /* M_TRIM_THRESHOLD is the maximum amount of freed top-most memory > > * to keep before releasing to the OS > > * Default is way too big: 256k > > */ > >mallopt(M_TRIM_THRESHOLD, 2 * PAGE_SIZE); > > #endif > > #ifdef M_MMAP_THRESHOLD > >/* M_MMAP_THRESHOLD is the request size threshold for using mmap() > > * Default is too big: 256k > > */ > >mallopt(M_MMAP_THRESHOLD, 8 * PAGE_SIZE - 256); > > #endif > > > > i doubt we need to tweak the mmap strategy, but i like the checks for the > > definitions of mallopt there. for portability to non-unix-y systems, we > > could wrap this whole thing in a #ifndef Q_WS_WIN block which should keep > > the KDE Windows team from pulling their hair out over the use of such > > UNIX-y API ;) sysconf(_SC_PAGESIZE) returns the page size for mmap, no need for (4*1024) - Ivan --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101385/#review3402 --- On May 18, 2011, 8:53 p.m., Philipp Knechtges wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101385/ > --- > > (Updated May 18, 2011, 8:53 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 > - > > kwin/composite.cpp 9edb99d > kwin/main.cpp f767f54 > > Diff: http://git.reviewboard.kde.org/r/101385/diff > > > Te
Re: Review Request: Fixing massive memory consumption in KWin using the raster graphicssystem.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101385/#review3402 --- those are some impressive results. my guess is that we likely have a very similar issue in plasma. in both cases, we are dealing with lots of small bits of memory in the form of pixmaps, strings, etc. that are fairly constantly coming and going. switching between compositing and no compositing is probably the 'worst case' real world scenario for this. if this does test out well, i'd suggest putting this code in libkworkspace so that all of our apps with this usage pattern (plasma-desktop, plasma-netbook, krunner, kwin, ..) can take advantage of a common implementation. a set of static methods in the KWorkspace namespace should suffice. if you could repeat your experiment with plasma-desktop with and without such a patch, that would be great and let us know whether we should adopt such a strategy across the plasma shell components. as for portability ... i'm not overly concerned about the portability of this to non-glibc systems as those systems are our primary targets. however, instead of checking for GLIBC the code could simply check for M_TRIM_THRESHOLD. for comparison, here is how busybox does this same trick for both the trim size and mmap request size threshold: #ifndef PAGE_SIZE # define PAGE_SIZE (4*1024) /* guess */ #endif #ifdef M_TRIM_THRESHOLD /* M_TRIM_THRESHOLD is the maximum amount of freed top-most memory * to keep before releasing to the OS * Default is way too big: 256k */ mallopt(M_TRIM_THRESHOLD, 2 * PAGE_SIZE); #endif #ifdef M_MMAP_THRESHOLD /* M_MMAP_THRESHOLD is the request size threshold for using mmap() * Default is too big: 256k */ mallopt(M_MMAP_THRESHOLD, 8 * PAGE_SIZE - 256); #endif i doubt we need to tweak the mmap strategy, but i like the checks for the definitions of mallopt there. for portability to non-unix-y systems, we could wrap this whole thing in a #ifndef Q_WS_WIN block which should keep the KDE Windows team from pulling their hair out over the use of such UNIX-y API ;) - Aaron J. On May 18, 2011, 8:53 p.m., Philipp Knechtges wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101385/ > --- > > (Updated May 18, 2011, 8:53 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 > - > > kwin/composite.cpp 9edb99d > kwin/main.cpp f767f54 > > 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
Review Request: Fixing massive memory consumption in KWin using the raster graphicssystem.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101385/ --- 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 - kwin/composite.cpp 9edb99d kwin/main.cpp f767f54 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
