From bb1ee72e6f2727e35164b8fcd29afa2bf6b9f283 Mon Sep 17 00:00:00 2001 From: Michael Kerrisk Date: Sun, 30 Aug 2015 03:22:02 -0700 Subject: [PATCH] mallopt.3: Minor tweaks to Carlos's patch Signed-off-by: Michael Kerrisk --- man3/mallopt.3 | 54 +++++++++++++++++++++++++++++++------------------- 1 file changed, 34 insertions(+), 20 deletions(-) diff --git a/man3/mallopt.3 b/man3/mallopt.3 index 53d17a070..c09e801a1 100644 --- a/man3/mallopt.3 +++ b/man3/mallopt.3 @@ -46,34 +46,48 @@ The following values can be specified for .IR param : .TP .BR M_ARENA_MAX -is the maximum number of arenas that can be created. The value of -M_ARENA_TEST is not used when M_ARENA_MAX is defined. -An arena represents a pool of memory that can be used by malloc -calls to service allocation requests. Arenas are thread safe and -therefore may have multiple concurrent memory requests. The -trade-off is between number of threads and number of arenas. -The more arenas you have the lower the per-thread contention, +This is the maximum number of arenas that can be created. +The value of +.B M_ARENA_TEST +is not used when +.B M_ARENA_MAX +is defined. +An arena represents a pool of memory that can be used by +.BR malloc (3) +(and similar) calls to service allocation requests. +Arenas are thread safe and +therefore may have multiple concurrent memory requests. +The trade-off is between the number of threads and the number of arenas. +The more arenas you have, the lower the per-thread contention, but the higher the memory usage. This parameter has been available since glibc 2.10 via ---enable-experimental-malloc, or glibc 2.15 by default. +.BR \-\-enable\-experimental\-malloc , +and since glibc 2.15 by default. In some versions of the allocator there was no limit on the number -of created arenas e.g. CentOS 5, RHEL 5. When running programs on -newer glibc these applications may exhibit high contention when -accessing arenas. In these cases it may be beneficial to increase -M_ARENA_MAX to match the number of threads. This is similar in behaviour -to strategies taken by tcmalloc and jemalloc e.g. per-thread allocation -pools. +of created arenas (e.g., CentOS 5, RHEL 5). + +When running programs on newer glibc versions, +these applications may exhibit high contention when accessing arenas. +In these cases, it may be beneficial to increase +.B M_ARENA_MAX +to match the number of threads. +This is similar in behavior to strategies taken by tcmalloc and jemalloc +(e.g., per-thread allocation pools). .TP .BR M_ARENA_TEST -is the limit, in number of arenas created, at which the system +This is the limit, in number of arenas created, at which the system configuration will be examined to evaluate a hard limit on the -number of created arenas. The computed limit is implementation -defined and usually a multiple of the number of available cores. -Once the limit is computed the result is final and constrains +number of created arenas. +The computed limit is implementation-defined +and is usually a multiple of the number of available cores. +Once the limit is computed, the result is final and constrains the total number of arenas. -See M_ARENA_MAX for the definition of an arena. +See +.B M_ARENA_MAX +for the definition of an arena. This parameter has been available since glibc 2.10 via ---enable-experimental-malloc, or glibc 2.15 by default. +.BR \-\-enable\-experimental\-malloc , +and since glibc 2.15 by default. .TP .BR M_CHECK_ACTION Setting this parameter controls how glibc responds when various kinds