LDP
/
man-pages
mirror of https://github.com/mkerrisk/man-pages
0
1
Fork 0
Code Releases Activity

mallopt.3: Minor tweaks to Carlos's patch 

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2015-08-30 03:22:02 -07:00
parent 9d116bd272
commit bb1ee72e6f
1 changed files with 34 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

54
man3/mallopt.3
View File

@ -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