From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15812 invoked by alias); 18 Oct 2016 16:03:35 -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 15788 invoked by uid 89); 18 Oct 2016 16:03:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=HX-HELO:sk:mail-wm, H*RU:sk:mail-wm, H*r:sk:mail-wm, Hx-spam-relays-external:sk:mail-wm X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-wm0-f65.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=24+5iqL9JWPMwiEMc1zP35lYfqTaIHTVg3jmsqf13os=; b=J84sESJaVh+EEo66qLjVVxDjSUs10qbgq7VxKR+WwqEdAQDMIztqUabyA5TwUMl83m xVN+5I+iX7//TZ94qPdtQiGSo3B+GjAlwv1lll/3mwX7Pt+eovjVXJIeeXb9CItMo2ro VLBe35OevXl927Qcpk7oKrXmIazikO83c8kZC6VC9UA9jc+6UJK7B60Cq+51MAPE3lfg a4nFNOp7n0GqQMirZqegOz/OMdDpgHfXf1QF577qshgFnOsjUO7RX77Og82yQinj18sG mWklVNhT53ro6p+zvZTw3/+tUblDukbzlRLg+I1EYaITI7+KTyq3kIlsiznlJ+VbDYtE efpA== X-Gm-Message-State: AA6/9Rk4V2oHpExCUoSAfANgpaHAuR0RIF/xxTQYTYopqVPiHFvl9mRWO4gM/3WFkYfGTw== X-Received: by 10.28.191.3 with SMTP id p3mr12910585wmf.112.1476806602174; Tue, 18 Oct 2016 09:03:22 -0700 (PDT) Subject: Re: [PATCH 2/2] Document the M_ARENA_* mallopt parameters To: siddhesh@sourceware.org, Carlos O'Donell 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> <33f30947-9f11-363e-3f35-6c593632f000@sourceware.org> Cc: mtk.manpages@gmail.com, libc-alpha From: "Michael Kerrisk (man-pages)" Message-ID: Date: Tue, 18 Oct 2016 16:03: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: <33f30947-9f11-363e-3f35-6c593632f000@sourceware.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00309.txt.bz2 Hi Siddhesh, On 10/18/2016 04:30 PM, Siddhesh Poyarekar wrote: > 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. Okay. > 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. D'oh! Yes, of course. Thanks for that. Not sure how I managed to misread that code :-}. So a better formulation would be something like: The default value of this parameter is 0, meaning that the limit on the number of arenas is determined according to the setting of M_ARENA_TEST. Seem okay? Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/