doc: strongly recommend MALLOC_MMAP_THRESHOLD_=131072 for glibc

The 131072 byte lower bound was the old default before the
sliding mmap window was introduced in modern glibc malloc.
While the sliding mmap window was intended to be faster by
reducing syscalls, zeroing and kernel overhead, it is also prone
to fragmentation from allocation patterns seen in evented Perl
servers.

Individual allocations over 128K are rare in our codebase since
there aren't many messages this large, making any performance
impact tiny.  Furthermore, the reduction in fragmentation and
memory use will be a speedup for memory-constrained systems
since they can avoid swap and have more leftover for the page
cache.

1 files changed, 4 insertions, 5 deletions

diff --git a/Documentation/public-inbox-tuning.pod b/Documentation/public-inbox-tuning.pod
index 7d0690b4..892ee0f2 100644
--- a/Documentation/public-inbox-tuning.pod
+++ b/Documentation/public-inbox-tuning.pod
@@ -165,11 +165,10 @@ capacity planning.
 
 Bursts of small object allocations late in process life contribute to
 fragmentation of the heap due to arenas (slabs) used internally by Perl.
-jemalloc (tested as an LD_PRELOAD on GNU/Linux) reduces
-overall fragmentation compared to glibc malloc in long-lived processes.
-glibc malloc users may try setting C<MALLOC_MMAP_THRESHOLD_> to a lower
-value (e.g. 131072) but that may require increasing the
-C<sys.vm.max_map_count> sysctl.
+glibc malloc users should use C<MALLOC_MMAP_THRESHOLD_=131072> to reduce
+fragmentation from the sliding mmap window.  jemalloc (tested as an
+LD_PRELOAD on GNU/Linux) also reduces fragmentation compared to an
+unconfigured glibc malloc in long-lived processes.
 
 =head2 Other OS tuning knobs