M_TRIM_THRESHOLD: the size of the smallest chunk of freed memory that causes the memory management system to shrink the data segment by calling brk(). In fact, as mentioned in the article, freed data is not given back to the system immediately in order to minimize the number of system calls. This parameter specifies how much memory has to be freed before such a call takes place. The value of the trim threshold influences the performance of your system. If the value is too high, more memory is retained and the system is more likely to resort to slow swap space accesses. Conversely, very small values degrade the overall performance because of frequent brk() calls. This parameter is crucial in long-lived programs, where too-high values could drain a lot of memory from the system. Also, it is important to point out that “locked” chunks (in the sense explained in the article) cannot be given back to the system even if their size is larger than this threshold—that's what mmap() allocation is for. The program shown in Listing 1 sets the threshold to the value passed as the parameter, then allocates and frees 100KB. You can observe the results in Listing 2.
M_TOP_PAD: how much slack space should be allocated (left) whenever brk() is called to expand (shrink) the heap. When a malloc() requiring a call to brk() is executed, this amount of extra space is requested from the system. Conversely, upon a free() call that would trigger a negative brk(), this amount of extra space is kept by the library for future use. Setting this parameter to an optimized value is envisaged when your program executes a lot of subsequent malloc()s and free()s, which could result in a lot of brk() calls.
M_MMAP_THRESHOLD: any memory request for a block larger than this threshold is served by calling mmap() instead of brk(). As already mentioned, the main advantage of this approach is the memory occupied by this block, once freed, is immediately made available to the system and is not retained until the trim threshold is met, as was the case for memory obtained from brk(). Using lower values for this parameter, thus increasing the occurrence of mmap()s vs. brk()s, has the advantage of keeping around less locked chunks. The disadvantage is mmap() generally is slower than brk() at providing memory, so it is often safer to leave the default value of this parameter untouched.
M_MMAP_MAX: the maximum number of memory chunks that can be served from mmap() at the same time. This parameter is relevant for systems that have a limitation on the maximum number of outstanding mmap()s. It is generally safe to leave this untouched.
M_MXFAST: the maximum size of a requested block that is served by using optimized memory containers called fastbins. We have no room here to deal with internal details, but all you need to know is fastbins are efficient when you are allocating and freeing a lot of small blocks of the same size. Anyway, because fastbins are never consolidated (that is, two adjacent free fastbins are never merged into a larger free block), their usage increases memory fragmentation and the overall memory occupation of your program. As a consequence, the value of this parameter must be a compromise between speed gain (smaller fastbins) and induced fragmentation (bigger fastbins). Small values are generally better, because the GNU C library is optimized in such a way that large fastbins cause a lot of fragmentation without yielding a noticeable speed boost. Fastbin support was introduced in the GNU C library with the complete rewrite of the malloc routines that took place in version 2.3.
