diff mbox series

Remove upper limit on tunable MALLOC_MMAP_THRESHOLD

Message ID b04a48ae-34d2-0c66-eb3f-10c1a4557429@oracle.com
State Superseded
Headers
Series Remove upper limit on tunable MALLOC_MMAP_THRESHOLD |

Checks

Context Check Description
dj/TryBot-apply_patch fail Patch failed to apply to master at the time it was sent
dj/TryBot-32bit fail Patch series failed to apply

Commit Message

Patrick McGehearty Oct. 28, 2021, 10:31 p.m. UTC 
  Attempts to set the MALLOC_MMAP_THRESHOLD higher than 1 Mbyte (for
32-bit apps) or 32 Mbytes (for 64-bit apps) are ignored with no
warnings issues. These limits are not documented in the manual where
malloc tuning is discussed. This value was set by a patch patch dated
2006 (15 years ago).

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
proposed 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.

No defaults for malloc tunables are changed. The default behavior of
malloc including the code to make dynamic changes to the mmap
threshold is unchanged. Therefore there will be no performance impact
of this change for those who accept the default behavior.

Only advanced users will be considering changing the limits. They
might be expected to only change these limits after profiling shows
that frequent mmap calls from malloc are a performance issue.
They will set the threshold according to the needs of their application
and will get the currently documented behavior instead of malloc
quietly ignoring their request when it was over the hidden
threshold.

One might ask if there is a risk in allowing an extremely large
threshold, even larger than all available memory. If the user were to
use an 'extremely large' value for the mmap threshold, the effect will
be the same as when the user uses tunables to totally disable the use
of mmap. As that is currently allowed, no additional harm is done if
the user finds an alternate way to get the same behavior.

The limitations of the current threshold was discovered by an advanced
researcher who was investigating setting the mmap threshold larger
than 32MBytes. By removing the limit, we free the user to experiment
with large values that might be appropriate for future systems that
have extremely large memory per core by today's standards.

modified: malloc/malloc.c
---
  malloc/malloc.c | 15 +++++----------
  1 file changed, 5 insertions(+), 10 deletions(-)

  static __always_inline int
diff mbox series

Patch

diff --git a/malloc/malloc.c b/malloc/malloc.c
index 2ba1fee..ce355e5 100644
--- a/malloc/malloc.c
+++ b/malloc/malloc.c
@@ -5223,16 +5223,11 @@  do_set_top_pad (size_t value)
  static __always_inline int
  do_set_mmap_threshold (size_t value)
  {
-  /* Forbid setting the threshold too high.  */
-  if (value <= HEAP_MAX_SIZE / 2)
-    {
-      LIBC_PROBE (memory_mallopt_mmap_threshold, 3, value, 
mp_.mmap_threshold,
-          mp_.no_dyn_threshold);
-      mp_.mmap_threshold = value;
-      mp_.no_dyn_threshold = 1;
-      return 1;
-    }
-  return 0;
+  LIBC_PROBE (memory_mallopt_mmap_threshold, 3, value, mp_.mmap_threshold,
+          mp_.no_dyn_threshold);
+  mp_.mmap_threshold = value;
+  mp_.no_dyn_threshold = 1;
+  return 1;
  }