From: shyouhei@... Date: 2018-08-10T02:07:36+00:00 Subject: [ruby-core:88411] [Ruby trunk Feature#14759] [PATCH] set M_ARENA_MAX for glibc malloc Issue #14759 has been updated by shyouhei (Shyouhei Urabe). normalperson (Eric Wong) wrote: > shyouhei@ruby-lang.org wrote: > > Yes the question is, what exactly is the value of > > MALLOC_ARENA_MAX that a user should specify to let malloc > > behave as it works in 2.5 now? > > (Etc.nprocessors * 8) on 64-bit, (Etc.nprocessors * 2) on 32-bit. Hmm. Thank you. Now I am very faintly negative because MALLOC_ARENA_MAX=2 ruby ... is much easier than MALLOC_ARENA_MAX=$((`ls -1 /sys/bus/cpu/devices/|wc -l`*8)) ruby... ---------------------------------------- Feature #14759: [PATCH] set M_ARENA_MAX for glibc malloc https://bugs.ruby-lang.org/issues/14759#change-73462 * Author: normalperson (Eric Wong) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- Not everybody benefits from jemalloc and the extra download+install time is not always worth it. Lets make the user experience for glibc malloc users better, too. Personally, I prefer using M_ARENA_MAX=1 (via MALLOC_ARENA_MAX env) myself, but there is currently a performance penalty for that. gc.c (Init_GC): set M_ARENA_MAX=2 for glibc malloc glibc malloc creates too many arenas and leads to fragmentation. Given the existence of the GVL, clamping to two arenas seems to be a reasonable trade-off for performance and memory usage. Some users (including myself for several years, now) prefer only one arena, now, so continue to respect users' wishes when MALLOC_ARENA_MAX is set. Thanks to Mike Perham for the reminder [ruby-core:86843] This doesn't seem to conflict with jemalloc, so it should be safe for all glibc-using systems. ---Files-------------------------------- 0001-gc.c-Init_GC-set-M_ARENA_MAX-2-for-glibc-malloc.patch (1.46 KB) -- https://bugs.ruby-lang.org/ Unsubscribe: