<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Mar 6, 2015, at 5:26 PM, Steve Cobb <<a href="mailto:stevecobb47@yahoo.com" class="">stevecobb47@yahoo.com</a>> wrote:<div><blockquote type="cite" class=""><div class=""><div class=""><div style="background-color: rgb(255, 255, 255); font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;" class=""><div id="yui_3_16_0_1_1425589253370_75895" dir="ltr" class="">I am busily reading web pages etc about tuning jemalloc etc, but would like to get some direct comments on how aggressive jemalloc is at releasing freed memory to the system - either by munmap or madvise(MADV_DONTNEED).</div><div id="yui_3_16_0_1_1425589253370_75953" dir="ltr" class=""><br class=""></div><div id="yui_3_16_0_1_1425589253370_75942" dir="ltr" class="">The problem we are facing - this is using glibc malloc, on embedded systems running Linux - is that we have applications that can scale way up in size, then scale way down. These systems have no swap partition. Using some tools to dump the heaps of these applications, after the scale-down, we find large chunks of memory retained on malloc free lists, but none of that memory can be trimmed from the heap and unmapped. This is on the order of 100s of M free, with contiguous blocks of of 50M on the free lists.</div><div id="yui_3_16_0_1_1425589253370_76024" dir="ltr" class=""><br class=""></div><div id="yui_3_16_0_1_1425589253370_76025" dir="ltr" class="">It turns out that glibc malloc appears very reluctant to trim its arenas. Particularly, the "main arena" is allocated via sbrk, and that can obviously only shrink at the end of the sbrk value. But the mmap'd arena's, one would hope would be more easily trimmed, but that does not seem to be the case.</div><div id="yui_3_16_0_1_1425589253370_76129" dir="ltr" class=""><br class=""></div><div id="yui_3_16_0_1_1425589253370_76131" dir="ltr" class="">So we are looking at jemalloc in hopes of solving this problem. <br class=""></div><div id="yui_3_16_0_1_1425589253370_76154" dir="ltr" class=""><br class=""></div><div id="yui_3_16_0_1_1425589253370_76155" dir="ltr" class="">I hope I have made my question clear. Can someone point out the basic implementation details here - the bottom line question is: how aggresive is jemalloc at returning memory to the system, and are there any tuning knobs for this type of behavior.</div></div></div></div></blockquote><br class=""></div><div>jemalloc is moderately aggressive about returning memory to the system by default, and it can be tuned to be very aggressive. See the lg_dirty_mult option for more information.</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span><a href="http://www.canonware.com/download/jemalloc/jemalloc-latest/doc/jemalloc.html#opt.lg_dirty_mult" class="">http://www.canonware.com/download/jemalloc/jemalloc-latest/doc/jemalloc.html#opt.lg_dirty_mult</a></div><div><br class=""></div><div>Jason</div><br class=""></body></html>