public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Siddhesh Poyarekar <siddhesh@sourceware.org>
To: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>,
	Carlos O'Donell <carlos@redhat.com>
Cc: libc-alpha <libc-alpha@sourceware.org>
Subject: Re: [PATCH 2/2] Document the M_ARENA_* mallopt parameters
Date: Tue, 18 Oct 2016 16:46:00 -0000	[thread overview]
Message-ID: <968422de-27f2-3359-6a76-61c152c253dd@sourceware.org> (raw)
In-Reply-To: <ca2e2f8d-f889-2dc6-3c30-9894403044e2@gmail.com>

On Tuesday 18 October 2016 09:33 PM, Michael Kerrisk (man-pages) wrote:
>>> 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.

No, it is not the value of M_ARENA_TEST :)

M_ARENA_TEST is set by default to NARENAS_FROM_CORES(1).  The limit on
the number of arenas is decided after M_ARENA_TEST number of arenas have
already created, but it is actually set to NARENAS_FROM_CORES(n), where
n is the number of cores.  If we can't find the number of cores for some
reason, then we set the limit to NARENAS_FROM_CORES(2).

So something like this is more accurate:

    The default value of this parameter is 0, meaning that the limit on
    the number of arenas is determined by the number of CPU cores
    online and the size of the '''long''' datatype.  For 32-bit systems
    the limit of on the number of arenas is 2 * '''number of CPU cores
    online''' while 64-bit systems, the limit on the number of arenas
    is 8 * '''number of CPU cores online'''.  If information on CPU
    cores is not available, it is assumed that there are 2 CPU cores
    online.

I have implicitly stated here that 32-bit long == 32-bit pointers since
I don't think there are Unix systems that have 32-bit long and 64-bit
pointers and also because the choice of multipliers for cores (2 and 8)
correlates better to the size of the address space than to size of long.

Siddhesh

  reply	other threads:[~2016-10-18 16:46 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-10 17:26 [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables Siddhesh Poyarekar
2016-10-10 17:26 ` [PATCH 2/2] Document the M_ARENA_* mallopt parameters Siddhesh Poyarekar
2016-10-17 14:04   ` [PING][PATCH " Siddhesh Poyarekar
2016-10-17 16:09   ` [PATCH " Carlos O'Donell
2016-10-18  7:15     ` Michael Kerrisk
2016-10-18 10:07       ` Siddhesh Poyarekar
2016-10-18 13:50         ` Michael Kerrisk (man-pages)
2016-10-18 14:30           ` Siddhesh Poyarekar
2016-10-18 16:03             ` Michael Kerrisk (man-pages)
2016-10-18 16:46               ` Siddhesh Poyarekar [this message]
2016-10-18 17:18                 ` Andreas Schwab
2016-10-19  6:53                 ` Michael Kerrisk (man-pages)
2016-10-19  7:09                   ` Siddhesh Poyarekar
2016-10-10 17:33 ` [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables DJ Delorie
2016-10-10 17:42   ` Siddhesh Poyarekar
2016-10-11  6:20   ` Michael Kerrisk
2016-10-11 18:19     ` DJ Delorie
2016-10-11 19:03       ` Michael Kerrisk (man-pages)
2016-10-12 11:57       ` Siddhesh Poyarekar
2016-10-17 19:40     ` Carlos O'Donell
2016-10-11 19:35 ` Kalle Olavi Niemitalo
2016-10-17 14:04 ` [PING][PATCH " Siddhesh Poyarekar
2016-10-17 16:13 ` [PATCH " Carlos O'Donell
2016-10-17 16:16   ` Siddhesh Poyarekar
2016-10-24 14:08 [PATCH 0/2] Malloc manual cleanups Siddhesh Poyarekar
2016-10-24 14:08 ` [PATCH 2/2] Document the M_ARENA_* mallopt parameters Siddhesh Poyarekar
2016-10-25  7:51   ` Rical Jasan
2016-10-25 21:55   ` DJ Delorie
2016-10-26  5:42     ` Siddhesh Poyarekar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=968422de-27f2-3359-6a76-61c152c253dd@sourceware.org \
    --to=siddhesh@sourceware.org \
    --cc=carlos@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=mtk.manpages@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).