From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89922 invoked by alias); 18 Oct 2016 14:30:28 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 89726 invoked by uid 89); 18 Oct 2016 14:30:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_NEUTRAL autolearn=no version=3.3.2 spammy=Hx-languages-length:2587, concluded X-HELO: homiemail-a57.g.dreamhost.com Reply-To: siddhesh@sourceware.org Subject: Re: [PATCH 2/2] Document the M_ARENA_* mallopt parameters References: <1476120388-26662-1-git-send-email-siddhesh@sourceware.org> <1476120388-26662-2-git-send-email-siddhesh@sourceware.org> <8183dc36-7d6a-bbfc-b6ff-568a2de8af28@redhat.com> To: "Michael Kerrisk (man-pages)" , Carlos O'Donell Cc: libc-alpha From: Siddhesh Poyarekar Message-ID: <33f30947-9f11-363e-3f35-6c593632f000@sourceware.org> Date: Tue, 18 Oct 2016 14:30:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00302.txt.bz2 On Tuesday 18 October 2016 07:20 PM, Michael Kerrisk (man-pages) wrote: > Hi Siddhesh, > > On 10/18/2016 12:07 PM, Siddhesh Poyarekar wrote: >> On Tuesday 18 October 2016 12:45 PM, Michael Kerrisk wrote: >>> So my reading from malloc/malloc.c: >>> >>> #define NARENAS_FROM_NCORES(n) ((n) * (sizeof (long) == 4 ? 2 : 8)) >>> .arena_test = NARENAS_FROM_NCORES (1) >>> >>> So, the default value for this parameter is 2 on systems where >>> sizeof(long) is 4; otherwise the default value is 8. >> >> That is correct. > > Thanks for the confirmation. > > [You've over trimmed the mail for this next piece. To be clear, below, > we are talking about M_ARENA_MAX; or at least I was.] > >>> So, IIUC, the default value of this parameter is 0, meaning that there >>> is no limit on the number of arenas that can be created. Do you >>> confirm, Siddhesh? >> >> No, the default is a function of the number of cores using the >> NARENAS_FROM_NCORES macro. That is, 2 * (number of cores) where >> sizeof(long) == 4 and 8 * (number of cores) otherwise. If the number of >> cores is not available (i.e. we can't read this info for some reason) >> then we default to 4 and 16 respectively, i.e. assume 2 cores. >> >> Note that this default only comes into force once the number of arenas >> cross arena_test. > > I don't think you're correct here. 'arena_max' is a field in a static > structure that is not otherwise initialized, AFAICT. So, it has the > value zero. (Some dirty hacking with a program that uses > malloc_get_state() and inspects the internal data structure seems > to confirm this.) > > And then in malloc/arena.c we have > > if (mp_.arena_max != 0) > narenas_limit = mp_.arena_max; > else if (narenas > mp_.arena_test) > { > int n = __get_nprocs (); > > if (n >= 1) > narenas_limit = NARENAS_FROM_NCORES (n); > else > /* We have no information about the system. Assume two > cores. */ > narenas_limit = NARENAS_FROM_NCORES (2); > > So, I believe my original statement about M_ARENA_MAX is correct. > Have I missed something? You're right in that the variable arena_max is initialized to 0. However you also concluded that there is no limit to the number of arenas that can be created when arena_max is 0, which is incorrect. As the code snippet you pasted above shows that if arena_max is 0, once we cross arena_test arenas, the narenas_limit static variable is set to a default upper limit based on the number of cores. That acts as the upper limit to the number of arenas that can be created when arena_max is 0. Siddhesh