From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-2.7 required=3.0 tests=BAYES_00,FORGED_HOTMAIL_RCVD2, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_PASS shortcircuit=no autolearn=no autolearn_force=no version=3.4.0 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 3756C1F406 for ; Wed, 16 May 2018 05:03:41 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 80ED31209D1; Wed, 16 May 2018 14:03:38 +0900 (JST) Received: from o1678948x4.outbound-mail.sendgrid.net (o1678948x4.outbound-mail.sendgrid.net [167.89.48.4]) by neon.ruby-lang.org (Postfix) with ESMTPS id 3A27B1209C1 for ; Wed, 16 May 2018 14:03:36 +0900 (JST) Received: by filter0028p3iad2.sendgrid.net with SMTP id filter0028p3iad2-19794-5AFBBBA4-55 2018-05-16 05:03:32.605714155 +0000 UTC Received: from herokuapp.com (ec2-50-19-172-60.compute-1.amazonaws.com [50.19.172.60]) by ismtpd0008p1iad1.sendgrid.net (SG) with ESMTP id zYz9ulYeS9W1BpNDLamPoQ Wed, 16 May 2018 05:03:32.396 +0000 (UTC) Date: Wed, 16 May 2018 05:03:33 +0000 (UTC) From: dennisb55@hotmail.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 62417 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 14759 X-Redmine-Issue-Author: normalperson X-Redmine-Sender: bluz71 X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS5/fNjHD+CR33tz2GoaBm+iK1oHmfR9Rq62bD dQsAS+D8de4aTxmSOLRfVKeDAZS3saxbtJcLSatsp+2zoXSzpL/ndGaak9quOmeizpE4QbRT7lCPqy xjavrio48ZK/BMjdGal7oRYQWBHUP5x52cXt+pxtX5gumpqFDre5mCjXRQ== X-ML-Name: ruby-core X-Mail-Count: 87059 Subject: [ruby-core:87059] [Ruby trunk Feature#14759] [PATCH] set M_ARENA_MAX for glibc malloc X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #14759 has been updated by bluz71 (Dennis B). normalperson (Eric Wong) wrote: > 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 This is not desirable in the longer term. CRuby will likely get true concurrency in the future via ko1's Guild proposal. Reducing arenas will create new contention and serialisation at the memory allocator level thus negating the full benefits of Guilds. Debate is currently occurring in [feature $14718](https://bugs.ruby-lang.org/issues/14718) about using jemalloc to solve Ruby's memory fragmentation issue on Linux. Resolution of that (one way or the other) should inform what to do here. I believe this should be paused until #14718 is clarified. ---------------------------------------- Feature #14759: [PATCH] set M_ARENA_MAX for glibc malloc https://bugs.ruby-lang.org/issues/14759#change-72019 * 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/