[ruby-core:88406] [Ruby trunk Feature#14759] [PATCH] set M_ARENA_MAX for glibc malloc

[shyouhei@ruby-lang.org]

Issue #14759 has been updated by shyouhei (Shyouhei Urabe).


normalperson (Eric Wong) wrote:
> shyouhei@ruby-lang.org wrote:
>  > One question: is it possible to cancel the effect of
>  > M_ARENA_MAX ?  Given @mame's corner case, it might be
>  > desirable for a user (or sysadmin) to be able to choose the
>  > behaviour between the proposed one and the status quo.
>  
>  Environment variable (MALLOC_ARENA_MAX) at startup (only),
>  or they can use fiddle or C extension to call mallopt
>  at anytime once a program is running.

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?

----------------------------------------
Feature #14759: [PATCH] set M_ARENA_MAX for glibc malloc
https://bugs.ruby-lang.org/issues/14759#change-73458

* 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/