diff options
author | Patrick McGehearty <patrick.mcgehearty@oracle.com> | 2021-12-16 00:43:24 +0000 |
---|---|---|
committer | Patrick McGehearty <patrick.mcgehearty@oracle.com> | 2021-12-16 17:24:37 +0000 |
commit | 0a4df6f5342620e0ac065b50a1b978123cd5e2f1 (patch) | |
tree | 7e36acf8e25d3da5848ced68286674e680e52076 /libio/tst-vtables-common.c | |
parent | a16c5ab13985a821a3671b77568040ddd14ab7a0 (diff) | |
download | glibc-0a4df6f5342620e0ac065b50a1b978123cd5e2f1.tar.gz glibc-0a4df6f5342620e0ac065b50a1b978123cd5e2f1.tar.xz glibc-0a4df6f5342620e0ac065b50a1b978123cd5e2f1.zip |
Remove upper limit on tunable MALLOC_MMAP_THRESHOLD
The current limit on MALLOC_MMAP_THRESHOLD is either 1 Mbyte (for 32-bit apps) or 32 Mbytes (for 64-bit apps). This value was set by a patch dated 2006 (15 years ago). Attempts to set the threshold higher are currently ignored. The default behavior is appropriate for many highly parallel applications where many processes or threads are sharing RAM. In other situations where the number of active processes or threads closely matches the number of cores, a much higher limit may be desired by the application designer. By today's standards on personal computers and small servers, 2 Gbytes of RAM per core is commonly available. On larger systems 4 Gbytes or more of RAM is sometimes available. Instead of raising the limit to match current needs, this patch proposes to remove the limit of the tunable, leaving the decision up to the user of a tunable to judge the best value for their needs. This patch does not change any of the defaults for malloc tunables, retaining the current behavior of the dynamic malloc mmap threshold. bugzilla 27801 - Remove upper limit on tunable MALLOC_MMAP_THRESHOLD Reviewed-by: DJ Delorie <dj@redhat.com> malloc/ malloc.c changed do_set_mmap_threshold to remove test for HEAP_MAX_SIZE.
Diffstat (limited to 'libio/tst-vtables-common.c')
0 files changed, 0 insertions, 0 deletions