From: dennisb55@... Date: 2018-05-19T03:04:53+00:00 Subject: [ruby-core:87187] [Ruby trunk Feature#14759] [PATCH] set M_ARENA_MAX for glibc malloc Issue #14759 has been updated by bluz71 (Dennis B). As discussed in [#14718](https://bugs.ruby-lang.org/issues/14718) I am now a strong supporter of this change. My prime concern, for the future, will be what to do when Guilds land? What do you think Eric? What should happen when Guilds become available? My thinking for arena count is maybe `max (2 || 0.5 * core-count)`. But that is just speculation. I think quite a bit of testing would need to occur with a proper Guild'ed Ruby benchmark. Also on the side (as you suggest) is continue to strive to improve glibc memory fragmentation behaviour (I assume by test cases and issue trackers and pull-requests)? ---------------------------------------- Feature #14759: [PATCH] set M_ARENA_MAX for glibc malloc https://bugs.ruby-lang.org/issues/14759#change-72178 * 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: