summary refs log tree commit diff
path: root/libio/bug-fseek.c
diff options
context:
space:
mode:
authorPatrick McGehearty <patrick.mcgehearty@oracle.com>2021-12-16 00:43:24 +0000
committerPatrick McGehearty <patrick.mcgehearty@oracle.com>2021-12-16 17:24:37 +0000
commit0a4df6f5342620e0ac065b50a1b978123cd5e2f1 (patch)
tree7e36acf8e25d3da5848ced68286674e680e52076 /libio/bug-fseek.c
parenta16c5ab13985a821a3671b77568040ddd14ab7a0 (diff)
downloadglibc-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/bug-fseek.c')
0 files changed, 0 insertions, 0 deletions