* [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables
@ 2016-10-10 17:26 Siddhesh Poyarekar
2016-10-10 17:26 ` [PATCH 2/2] Document the M_ARENA_* mallopt parameters Siddhesh Poyarekar
` (4 more replies)
0 siblings, 5 replies; 30+ messages in thread
From: Siddhesh Poyarekar @ 2016-10-10 17:26 UTC (permalink / raw)
To: libc-alpha
The mallopt parameters manual does not mention the environment
variables that can be used to set these parameters at program startup.
Mention those environment variables for completeness.
* manual/memory.texi: Add environment variable alternatives to
setting mallopt parameters.
---
manual/memory.texi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/manual/memory.texi b/manual/memory.texi
index 5383105..222f126 100644
--- a/manual/memory.texi
+++ b/manual/memory.texi
@@ -1113,12 +1113,18 @@ choices for @var{param}, as defined in @file{malloc.h}, are:
@item M_MMAP_MAX
The maximum number of chunks to allocate with @code{mmap}. Setting this
to zero disables all use of @code{mmap}.
+
+This parameter can also be set for the process at startup by setting the
+environment variable @code{MALLOC_MMAP_MAX_} to the desired value.
@item M_MMAP_THRESHOLD
All chunks larger than this value are allocated outside the normal
heap, using the @code{mmap} system call. This way it is guaranteed
that the memory for these chunks can be returned to the system on
@code{free}. Note that requests smaller than this threshold might still
be allocated via @code{mmap}.
+
+This parameter can also be set for the process at startup by setting the
+environment variable @code{MALLOC_MMAP_THRESHOLD_} to the desired value.
@comment TODO: @item M_MXFAST
@item M_PERTURB
If non-zero, memory blocks are filled with values depending on some
@@ -1128,16 +1134,25 @@ use of uninitialized or freed heap memory. Note that this option does not
guarantee that the freed block will have any specific values. It only
guarantees that the content the block had before it was freed will be
overwritten.
+
+This parameter can also be set for the process at startup by setting the
+environment variable @code{MALLOC_MMAP_PERTURB_} to the desired value.
@item M_TOP_PAD
This parameter determines the amount of extra memory to obtain from the
system when a call to @code{sbrk} is required. It also specifies the
number of bytes to retain when shrinking the heap by calling @code{sbrk}
with a negative argument. This provides the necessary hysteresis in
heap size such that excessive amounts of system calls can be avoided.
+
+This parameter can also be set for the process at startup by setting the
+environment variable @code{MALLOC_TOP_PAD_} to the desired value.
@item M_TRIM_THRESHOLD
This is the minimum size (in bytes) of the top-most, releasable chunk
that will cause @code{sbrk} to be called with a negative argument in
order to return memory to the system.
+
+This parameter can also be set for the process at startup by setting the
+environment variable @code{MALLOC_TRIM_THRESHOLD_} to the desired value.
@end table
@end deftypefun
--
2.7.4
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 2/2] Document the M_ARENA_* mallopt parameters
2016-10-10 17:26 [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables Siddhesh Poyarekar
@ 2016-10-10 17:26 ` Siddhesh Poyarekar
2016-10-17 14:04 ` [PING][PATCH " Siddhesh Poyarekar
2016-10-17 16:09 ` [PATCH " Carlos O'Donell
2016-10-10 17:33 ` [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables DJ Delorie
` (3 subsequent siblings)
4 siblings, 2 replies; 30+ messages in thread
From: Siddhesh Poyarekar @ 2016-10-10 17:26 UTC (permalink / raw)
To: libc-alpha
The M_ARENA_* mallopt parameters are in wide use in production to
control the number of arenas that a long lived process creates and
hence there is no point in stating that this interface is non-public.
Document this interface and remove the obsolete comment.
* manual/memory.texi (M_ARENA_TEST): Add documentation.
(M_ARENA_MAX): Likewise.
* malloc/malloc.c: Remove obsolete comment.
---
malloc/malloc.c | 1 -
manual/memory.texi | 21 +++++++++++++++++++++
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/malloc/malloc.c b/malloc/malloc.c
index 09e004b..0011a6d 100644
--- a/malloc/malloc.c
+++ b/malloc/malloc.c
@@ -1718,7 +1718,6 @@ static struct malloc_par mp_ =
};
-/* Non public mallopt parameters. */
#define M_ARENA_TEST -7
#define M_ARENA_MAX -8
diff --git a/manual/memory.texi b/manual/memory.texi
index 222f126..b98dcf2 100644
--- a/manual/memory.texi
+++ b/manual/memory.texi
@@ -1153,6 +1153,27 @@ order to return memory to the system.
This parameter can also be set for the process at startup by setting the
environment variable @code{MALLOC_TRIM_THRESHOLD_} to the desired value.
+
+@item M_ARENA_TEST
+An arena is a memory pool that is allocated to act as a heap alongside the
+system heap that the kernel creates for the process. This is to provide
+multiple heap structures for multiple threads of a process to reduce contention
+between them. The limit to the number of such arenas per process is determined
+by the number of cores of the system and whether it is a 32-bit or a 64-bit
+processor.
+
+The value is ignored if @code{M_ARENA_MAX} is set either via @code{mallopt} or
+via the @code{MALLOC_ARENA_MAX} environment variable.
+
+This parameter can also be set for the process at startup by setting the
+environment variable @code{MALLOC_ARENA_TEST} to the desired value.
+
+@item M_ARENA_MAX
+This parameter sets the number of arenas to use regardless of the number of
+cores in the system.
+
+This parameter can also be set for the process at startup by setting the
+environment variable @code{MALLOC_ARENA_MAX} to the desired value.
@end table
@end deftypefun
--
2.7.4
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PING][PATCH 2/2] Document the M_ARENA_* mallopt parameters
2016-10-10 17:26 ` [PATCH 2/2] Document the M_ARENA_* mallopt parameters Siddhesh Poyarekar
@ 2016-10-17 14:04 ` Siddhesh Poyarekar
2016-10-17 16:09 ` [PATCH " Carlos O'Donell
1 sibling, 0 replies; 30+ messages in thread
From: Siddhesh Poyarekar @ 2016-10-17 14:04 UTC (permalink / raw)
To: libc-alpha
Ping!
On Monday 10 October 2016 10:56 PM, Siddhesh Poyarekar wrote:
> The M_ARENA_* mallopt parameters are in wide use in production to
> control the number of arenas that a long lived process creates and
> hence there is no point in stating that this interface is non-public.
> Document this interface and remove the obsolete comment.
>
> * manual/memory.texi (M_ARENA_TEST): Add documentation.
> (M_ARENA_MAX): Likewise.
> * malloc/malloc.c: Remove obsolete comment.
> ---
> malloc/malloc.c | 1 -
> manual/memory.texi | 21 +++++++++++++++++++++
> 2 files changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/malloc/malloc.c b/malloc/malloc.c
> index 09e004b..0011a6d 100644
> --- a/malloc/malloc.c
> +++ b/malloc/malloc.c
> @@ -1718,7 +1718,6 @@ static struct malloc_par mp_ =
> };
>
>
> -/* Non public mallopt parameters. */
> #define M_ARENA_TEST -7
> #define M_ARENA_MAX -8
>
> diff --git a/manual/memory.texi b/manual/memory.texi
> index 222f126..b98dcf2 100644
> --- a/manual/memory.texi
> +++ b/manual/memory.texi
> @@ -1153,6 +1153,27 @@ order to return memory to the system.
>
> This parameter can also be set for the process at startup by setting the
> environment variable @code{MALLOC_TRIM_THRESHOLD_} to the desired value.
> +
> +@item M_ARENA_TEST
> +An arena is a memory pool that is allocated to act as a heap alongside the
> +system heap that the kernel creates for the process. This is to provide
> +multiple heap structures for multiple threads of a process to reduce contention
> +between them. The limit to the number of such arenas per process is determined
> +by the number of cores of the system and whether it is a 32-bit or a 64-bit
> +processor.
> +
> +The value is ignored if @code{M_ARENA_MAX} is set either via @code{mallopt} or
> +via the @code{MALLOC_ARENA_MAX} environment variable.
> +
> +This parameter can also be set for the process at startup by setting the
> +environment variable @code{MALLOC_ARENA_TEST} to the desired value.
> +
> +@item M_ARENA_MAX
> +This parameter sets the number of arenas to use regardless of the number of
> +cores in the system.
> +
> +This parameter can also be set for the process at startup by setting the
> +environment variable @code{MALLOC_ARENA_MAX} to the desired value.
> @end table
>
> @end deftypefun
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 2/2] Document the M_ARENA_* mallopt parameters
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 ` Carlos O'Donell
2016-10-18 7:15 ` Michael Kerrisk
1 sibling, 1 reply; 30+ messages in thread
From: Carlos O'Donell @ 2016-10-17 16:09 UTC (permalink / raw)
To: Siddhesh Poyarekar, libc-alpha
On 10/10/2016 01:26 PM, Siddhesh Poyarekar wrote:
> The M_ARENA_* mallopt parameters are in wide use in production to
> control the number of arenas that a long lived process creates and
> hence there is no point in stating that this interface is non-public.
> Document this interface and remove the obsolete comment.
>
> * manual/memory.texi (M_ARENA_TEST): Add documentation.
> (M_ARENA_MAX): Likewise.
> * malloc/malloc.c: Remove obsolete comment.
> ---
> malloc/malloc.c | 1 -
> manual/memory.texi | 21 +++++++++++++++++++++
> 2 files changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/malloc/malloc.c b/malloc/malloc.c
> index 09e004b..0011a6d 100644
> --- a/malloc/malloc.c
> +++ b/malloc/malloc.c
> @@ -1718,7 +1718,6 @@ static struct malloc_par mp_ =
> };
>
>
> -/* Non public mallopt parameters. */
> #define M_ARENA_TEST -7
> #define M_ARENA_MAX -8
>
> diff --git a/manual/memory.texi b/manual/memory.texi
> index 222f126..b98dcf2 100644
> --- a/manual/memory.texi
> +++ b/manual/memory.texi
> @@ -1153,6 +1153,27 @@ order to return memory to the system.
>
> This parameter can also be set for the process at startup by setting the
> environment variable @code{MALLOC_TRIM_THRESHOLD_} to the desired value.
> +
> +@item M_ARENA_TEST
This description of an arena doesn't belong here, it belongs higher up in the
manual, and in fact I would suggest the following:
- Move 3.2.2.6 "Efficiency considerations for malloc" up to just under
"Dynamic Memory allocation" and put it under a new subsection "The GNU allocator".
- Under "The GNU allocator" give a brief 1 paragraph description of how
the allocator works e.g. https://sourceware.org/glibc/wiki/MallocInternals
and talk about arenas.
> +An arena is a memory pool that is allocated to act as a heap alongside the
> +system heap that the kernel creates for the process. This is to provide
> +multiple heap structures for multiple threads of a process to reduce contention
> +between them. The limit to the number of such arenas per process is determined
> +by the number of cores of the system and whether it is a 32-bit or a 64-bit
> +processor.
You don't say what M_ARENA_TEST is for?
> +
> +The value is ignored if @code{M_ARENA_MAX} is set either via @code{mallopt} or
> +via the @code{MALLOC_ARENA_MAX} environment variable.
> +
> +This parameter can also be set for the process at startup by setting the
> +environment variable @code{MALLOC_ARENA_TEST} to the desired value.
What is the default?
> +
> +@item M_ARENA_MAX
> +This parameter sets the number of arenas to use regardless of the number of
> +cores in the system.
> +
> +This parameter can also be set for the process at startup by setting the
> +environment variable @code{MALLOC_ARENA_MAX} to the desired value.
What is the default?
> @end table
>
> @end deftypefun
>
--
Cheers,
Carlos.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 2/2] Document the M_ARENA_* mallopt parameters
2016-10-17 16:09 ` [PATCH " Carlos O'Donell
@ 2016-10-18 7:15 ` Michael Kerrisk
2016-10-18 10:07 ` Siddhesh Poyarekar
0 siblings, 1 reply; 30+ messages in thread
From: Michael Kerrisk @ 2016-10-18 7:15 UTC (permalink / raw)
To: Carlos O'Donell
Cc: Siddhesh Poyarekar, libc-alpha, Michael Kerrisk-manpages
On Mon, Oct 17, 2016 at 6:08 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 10/10/2016 01:26 PM, Siddhesh Poyarekar wrote:
>> The M_ARENA_* mallopt parameters are in wide use in production to
>> control the number of arenas that a long lived process creates and
>> hence there is no point in stating that this interface is non-public.
>> Document this interface and remove the obsolete comment.
>>
>> * manual/memory.texi (M_ARENA_TEST): Add documentation.
>> (M_ARENA_MAX): Likewise.
>> * malloc/malloc.c: Remove obsolete comment.
>> ---
>> malloc/malloc.c | 1 -
>> manual/memory.texi | 21 +++++++++++++++++++++
>> 2 files changed, 21 insertions(+), 1 deletion(-)
>>
>> diff --git a/malloc/malloc.c b/malloc/malloc.c
>> index 09e004b..0011a6d 100644
>> --- a/malloc/malloc.c
>> +++ b/malloc/malloc.c
>> @@ -1718,7 +1718,6 @@ static struct malloc_par mp_ =
>> };
>>
>>
>> -/* Non public mallopt parameters. */
>> #define M_ARENA_TEST -7
>> #define M_ARENA_MAX -8
>>
>> diff --git a/manual/memory.texi b/manual/memory.texi
>> index 222f126..b98dcf2 100644
>> --- a/manual/memory.texi
>> +++ b/manual/memory.texi
>> @@ -1153,6 +1153,27 @@ order to return memory to the system.
>>
>> This parameter can also be set for the process at startup by setting the
>> environment variable @code{MALLOC_TRIM_THRESHOLD_} to the desired value.
>> +
>> +@item M_ARENA_TEST
>
> This description of an arena doesn't belong here, it belongs higher up in the
> manual, and in fact I would suggest the following:
>
> - Move 3.2.2.6 "Efficiency considerations for malloc" up to just under
> "Dynamic Memory allocation" and put it under a new subsection "The GNU allocator".
>
> - Under "The GNU allocator" give a brief 1 paragraph description of how
> the allocator works e.g. https://sourceware.org/glibc/wiki/MallocInternals
> and talk about arenas.
>
>> +An arena is a memory pool that is allocated to act as a heap alongside the
>> +system heap that the kernel creates for the process. This is to provide
>> +multiple heap structures for multiple threads of a process to reduce contention
>> +between them. The limit to the number of such arenas per process is determined
>> +by the number of cores of the system and whether it is a 32-bit or a 64-bit
>> +processor.
>
> You don't say what M_ARENA_TEST is for?
>
>> +
>> +The value is ignored if @code{M_ARENA_MAX} is set either via @code{mallopt} or
>> +via the @code{MALLOC_ARENA_MAX} environment variable.
>> +
>> +This parameter can also be set for the process at startup by setting the
>> +environment variable @code{MALLOC_ARENA_TEST} to the desired value.
>
> What is the default?
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.
>> +
>> +@item M_ARENA_MAX
>> +This parameter sets the number of arenas to use regardless of the number of
>> +cores in the system.
>> +
>> +This parameter can also be set for the process at startup by setting the
>> +environment variable @code{MALLOC_ARENA_MAX} to the desired value.
>
> What is the default?
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?
Siddhesh, in case you want to use any of my wordings (assuming they
are correct), I place them in the public domain. (The text will also
land in the mallopt(3) manual page.)
Cheers,
Michael
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 2/2] Document the M_ARENA_* mallopt parameters
2016-10-18 7:15 ` Michael Kerrisk
@ 2016-10-18 10:07 ` Siddhesh Poyarekar
2016-10-18 13:50 ` Michael Kerrisk (man-pages)
0 siblings, 1 reply; 30+ messages in thread
From: Siddhesh Poyarekar @ 2016-10-18 10:07 UTC (permalink / raw)
To: Michael Kerrisk, Carlos O'Donell; +Cc: libc-alpha
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.
> 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.
> Siddhesh, in case you want to use any of my wordings (assuming they
> are correct), I place them in the public domain. (The text will also
> land in the mallopt(3) manual page.)
Thanks.
Siddhesh
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 2/2] Document the M_ARENA_* mallopt parameters
2016-10-18 10:07 ` Siddhesh Poyarekar
@ 2016-10-18 13:50 ` Michael Kerrisk (man-pages)
2016-10-18 14:30 ` Siddhesh Poyarekar
0 siblings, 1 reply; 30+ messages in thread
From: Michael Kerrisk (man-pages) @ 2016-10-18 13:50 UTC (permalink / raw)
To: siddhesh, Carlos O'Donell; +Cc: mtk.manpages, libc-alpha
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?
Cheers,
Michael
>> Siddhesh, in case you want to use any of my wordings (assuming they
>> are correct), I place them in the public domain. (The text will also
>> land in the mallopt(3) manual page.)
>
> Thanks.
>
> Siddhesh
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 2/2] Document the M_ARENA_* mallopt parameters
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)
0 siblings, 1 reply; 30+ messages in thread
From: Siddhesh Poyarekar @ 2016-10-18 14:30 UTC (permalink / raw)
To: Michael Kerrisk (man-pages), Carlos O'Donell; +Cc: libc-alpha
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 2/2] Document the M_ARENA_* mallopt parameters
2016-10-18 14:30 ` Siddhesh Poyarekar
@ 2016-10-18 16:03 ` Michael Kerrisk (man-pages)
2016-10-18 16:46 ` Siddhesh Poyarekar
0 siblings, 1 reply; 30+ messages in thread
From: Michael Kerrisk (man-pages) @ 2016-10-18 16:03 UTC (permalink / raw)
To: siddhesh, Carlos O'Donell; +Cc: mtk.manpages, libc-alpha
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/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 2/2] Document the M_ARENA_* mallopt parameters
2016-10-18 16:03 ` Michael Kerrisk (man-pages)
@ 2016-10-18 16:46 ` Siddhesh Poyarekar
2016-10-18 17:18 ` Andreas Schwab
2016-10-19 6:53 ` Michael Kerrisk (man-pages)
0 siblings, 2 replies; 30+ messages in thread
From: Siddhesh Poyarekar @ 2016-10-18 16:46 UTC (permalink / raw)
To: Michael Kerrisk (man-pages), Carlos O'Donell; +Cc: libc-alpha
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 2/2] Document the M_ARENA_* mallopt parameters
2016-10-18 16:46 ` Siddhesh Poyarekar
@ 2016-10-18 17:18 ` Andreas Schwab
2016-10-19 6:53 ` Michael Kerrisk (man-pages)
1 sibling, 0 replies; 30+ messages in thread
From: Andreas Schwab @ 2016-10-18 17:18 UTC (permalink / raw)
To: Siddhesh Poyarekar
Cc: Michael Kerrisk (man-pages), Carlos O'Donell, libc-alpha
On Okt 18 2016, Siddhesh Poyarekar <siddhesh@sourceware.org> wrote:
> 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
twice the
> online''' while 64-bit systems, the limit on the number of arenas
> is 8 * '''number of CPU cores online'''. If information on CPU
eight times the
> cores is not available, it is assumed that there are 2 CPU cores
> online.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 2/2] Document the M_ARENA_* mallopt parameters
2016-10-18 16:46 ` Siddhesh Poyarekar
2016-10-18 17:18 ` Andreas Schwab
@ 2016-10-19 6:53 ` Michael Kerrisk (man-pages)
2016-10-19 7:09 ` Siddhesh Poyarekar
1 sibling, 1 reply; 30+ messages in thread
From: Michael Kerrisk (man-pages) @ 2016-10-19 6:53 UTC (permalink / raw)
To: siddhesh, Carlos O'Donell; +Cc: mtk.manpages, libc-alpha
Hi Siddhesh,
On 10/18/2016 06:46 PM, Siddhesh Poyarekar wrote:
> 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 :)
I agree. But it's also not what I said ;-). I said "determined according
to the value of..."
Currently, the M_ARENA_TEST text in mallopt(3) says:
M_ARENA_TEST
This parameter specifies a value, in number of arenas creâ
ated, at which point the system configuration will be examâ
ined to determine a hard limit on the number of created
arenas. (See M_ARENA_MAX for the definition of an arena.)
The computation of the arena hard limit is implementation-
defined and is usually calculated as a multiple of the numâ
ber of available CPUs. Once the hard limit is computed,
the result is final and constrains the total number of areâ
nas.
The default value for the M_ARENA_TEST parameter is 2 on
systems where sizeof(long) is 4; otherwise the default
value is 8.
This parameter has been available since glibc 2.10 via
--enable-experimental-malloc, and since glibc 2.15 by
default.
The value of M_ARENA_TEST is not used when M_ARENA_MAX has
a nonzero value.
> 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.
Your details following are a little more precise. But I believe Carlos,
when he wrote the text about how the limit was calculated, deliberately
chose to be more vague. I'm okay with including this level of detail
in the man page, but, if I recall correctly, Carlos wanted to avoid it.
Cheers,
Michael
> 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
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 2/2] Document the M_ARENA_* mallopt parameters
2016-10-19 6:53 ` Michael Kerrisk (man-pages)
@ 2016-10-19 7:09 ` Siddhesh Poyarekar
0 siblings, 0 replies; 30+ messages in thread
From: Siddhesh Poyarekar @ 2016-10-19 7:09 UTC (permalink / raw)
To: Michael Kerrisk (man-pages), Carlos O'Donell; +Cc: libc-alpha
On Wednesday 19 October 2016 12:23 PM, Michael Kerrisk (man-pages) wrote:
> I agree. But it's also not what I said ;-). I said "determined according
> to the value of..."
Ahh, I wouldn't have caught that if you hadn't pointed it out.
> Your details following are a little more precise. But I believe Carlos,
> when he wrote the text about how the limit was calculated, deliberately
> chose to be more vague. I'm okay with including this level of detail
> in the man page, but, if I recall correctly, Carlos wanted to avoid it.
I'll let Carlos take the call on that. He asked for detail in the glibc
manual, so I'll propose that level and detail for the manual and see
what he thinks.
Siddhesh
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables
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-10 17:33 ` DJ Delorie
2016-10-10 17:42 ` Siddhesh Poyarekar
2016-10-11 6:20 ` Michael Kerrisk
2016-10-11 19:35 ` Kalle Olavi Niemitalo
` (2 subsequent siblings)
4 siblings, 2 replies; 30+ messages in thread
From: DJ Delorie @ 2016-10-10 17:33 UTC (permalink / raw)
To: Siddhesh Poyarekar; +Cc: libc-alpha
These variables all end with "_", most likely the original intention is
that they are not official and may be removed or changed at any time.
By making them official, we lock in that ABI. Is that your intention?
(likewise your other patch).
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables
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
1 sibling, 0 replies; 30+ messages in thread
From: Siddhesh Poyarekar @ 2016-10-10 17:42 UTC (permalink / raw)
To: DJ Delorie; +Cc: libc-alpha
On Monday 10 October 2016 11:03 PM, DJ Delorie wrote:
> These variables all end with "_", most likely the original intention is
> that they are not official and may be removed or changed at any time.
>
> By making them official, we lock in that ABI. Is that your intention?
>
> (likewise your other patch).
I don't see the point in not doing so because they're too widely in use
for us to take them back anyway.
Siddhesh
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables
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-17 19:40 ` Carlos O'Donell
1 sibling, 2 replies; 30+ messages in thread
From: Michael Kerrisk @ 2016-10-11 6:20 UTC (permalink / raw)
To: DJ Delorie; +Cc: Siddhesh Poyarekar, libc-alpha
On Mon, Oct 10, 2016 at 7:33 PM, DJ Delorie <dj@redhat.com> wrote:
>
> These variables all end with "_", most likely the original intention is
> that they are not official and may be removed or changed at any time.
>
> By making them official, we lock in that ABI. Is that your intention?
I think the notion that because one does not document something, it's
not an official part of the ABI is at best highly dubious. Especially
when so many "official" parts of the ABI are also not documented.
The only way that documentation might be able to help in such
situations is where pieces are clearly and loudly documented right
from the beginning, in the official documentation, as "not supported,
may disappear at any moment in the future, use at your own risk", but
even then people are likely to ignore the documentation or be unaware
of it.
And in any case, these environment vars have long been documented in
various "unofficial" places including (since 2012)
http://man7.org/linux/man-pages/man3/mallopt.3.html
Cheers,
Michael
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables
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
1 sibling, 2 replies; 30+ messages in thread
From: DJ Delorie @ 2016-10-11 18:19 UTC (permalink / raw)
To: Michael Kerrisk; +Cc: siddhesh, libc-alpha
Michael Kerrisk <mtk.manpages@gmail.com> writes:
> I think the notion that because one does not document something, it's
> not an official part of the ABI is at best highly dubious.
I wasn't here for the origin of those variables, I'm just thinking that
we use a leading underscore elsewhere to mean "not official" so the
trailing underscore here might have similar intent.
FTR I have no problem with documenting unsupported behavior, I just want
to make sure we understand how this patch affects the officialness of
this ABI.
> The only way that documentation might be able to help in such
> situations is where pieces are clearly and loudly documented right
> from the beginning, in the official documentation, as "not supported,
> may disappear at any moment in the future, use at your own risk", but
> even then people are likely to ignore the documentation or be unaware
> of it.
That would be fine too. My concern is: if we intended for those
variables to be unofficial before, do we want to (1) make them official
now, or (2) be careful not to *accidentally* make them official?
And if we decide they're official (and/or always have been), should we
add in variants without underscores to be the official ones?
So I guess the next step is to have someone in authority (or consensus?)
decide if those variables are "official" or not, and if they should
become so if not.
Based on that we may want to tweak the documentation patch, or the code.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables
2016-10-11 18:19 ` DJ Delorie
@ 2016-10-11 19:03 ` Michael Kerrisk (man-pages)
2016-10-12 11:57 ` Siddhesh Poyarekar
1 sibling, 0 replies; 30+ messages in thread
From: Michael Kerrisk (man-pages) @ 2016-10-11 19:03 UTC (permalink / raw)
To: DJ Delorie; +Cc: mtk.manpages, siddhesh, libc-alpha
On 10/11/2016 08:18 PM, DJ Delorie wrote:
>
> Michael Kerrisk <mtk.manpages@gmail.com> writes:
>> I think the notion that because one does not document something, it's
>> not an official part of the ABI is at best highly dubious.
>
> I wasn't here for the origin of those variables, I'm just thinking that
> we use a leading underscore elsewhere to mean "not official" so the
> trailing underscore here might have similar intent.
>
> FTR I have no problem with documenting unsupported behavior, I just want
> to make sure we understand how this patch affects the officialness of
> this ABI.
My thought is: not very much. The ABI is out there and is well known.
There's not really anyway to argue to users that it is not "official",
no matter what the original developers might once have thought about
these interfaces.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables
2016-10-11 18:19 ` DJ Delorie
2016-10-11 19:03 ` Michael Kerrisk (man-pages)
@ 2016-10-12 11:57 ` Siddhesh Poyarekar
1 sibling, 0 replies; 30+ messages in thread
From: Siddhesh Poyarekar @ 2016-10-12 11:57 UTC (permalink / raw)
To: DJ Delorie, Michael Kerrisk; +Cc: libc-alpha
On Tuesday 11 October 2016 11:48 PM, DJ Delorie wrote:
> I wasn't here for the origin of those variables, I'm just thinking that
> we use a leading underscore elsewhere to mean "not official" so the
> trailing underscore here might have similar intent.
I agree, that may have been the intent. However what happened
afterwards (i.e. their widespread use and the lack of communication to
the contrary from the then maintainers) have invalidated that intent
IMO. What's more, other important sources (the man pages, Red Hat
product documentation) document these environment variables and that
gives them as much a sense of credibility as anything else.
> And if we decide they're official (and/or always have been), should we
> add in variants without underscores to be the official ones?
I'll be adding in tunables, which would become the 'official' versions
of these envvars. Tunables come with the disclaimer that they may
disappear/reappear in releases, but I don't think we will do that for
the malloc tunables in practice.
> So I guess the next step is to have someone in authority (or consensus?)
> decide if those variables are "official" or not, and if they should
> become so if not.
It is usually consensus.
Siddhesh
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables
2016-10-11 6:20 ` Michael Kerrisk
2016-10-11 18:19 ` DJ Delorie
@ 2016-10-17 19:40 ` Carlos O'Donell
1 sibling, 0 replies; 30+ messages in thread
From: Carlos O'Donell @ 2016-10-17 19:40 UTC (permalink / raw)
To: Michael Kerrisk, DJ Delorie; +Cc: Siddhesh Poyarekar, libc-alpha
On 10/11/2016 02:20 AM, Michael Kerrisk wrote:
> On Mon, Oct 10, 2016 at 7:33 PM, DJ Delorie <dj@redhat.com> wrote:
>>
>> These variables all end with "_", most likely the original intention is
>> that they are not official and may be removed or changed at any time.
>>
>> By making them official, we lock in that ABI. Is that your intention?
>
> I think the notion that because one does not document something, it's
> not an official part of the ABI is at best highly dubious. Especially
> when so many "official" parts of the ABI are also not documented.
>
> The only way that documentation might be able to help in such
> situations is where pieces are clearly and loudly documented right
> from the beginning, in the official documentation, as "not supported,
> may disappear at any moment in the future, use at your own risk", but
> even then people are likely to ignore the documentation or be unaware
> of it.
>
> And in any case, these environment vars have long been documented in
> various "unofficial" places including (since 2012)
> http://man7.org/linux/man-pages/man3/mallopt.3.html
The things that DJ is worried about are the arena ones
e.g. M_ARENA_MAX, and M_ARENA_TEST and their env vars.
In 2013 I brought up the discussion about ABI implications:
https://sourceware.org/ml/libc-alpha/2013-03/msg00376.html
Only Siddhesh and I commented, and we both agreed it was a forgone
conclusion that these were stable parts of the ABI/API.
In 2015 I documented them in the linux man pages project:
https://www.sourceware.org/ml/libc-alpha/2015-08/msg00991.html
~~~
Consensus among Siddhesh and myself was that they should be public,
and in fact they were already in the public header. Therefore there
may already be applications uses these constants and expecting them
to work. At best we could limit mallopt's acceptance of the options,
but that seems like a bad solution that could lead to unexpected
behaviour for user applications. A quick google search shows that
there are packages relying on these constants to tune the glibc
malloc implementation.
~~~
They are part of the ABI and public, and should be documented
in the manual as Siddhesh's patches do.
We should however be very very circumspect about adding more
of these mallopt tunables without first seeing that such tunables
are stable and long-term useful as generic tunables (via the tunables
interface). So go review Siddhesh's patches on tunables :-)
--
Cheers,
Carlos.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables
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-10 17:33 ` [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables DJ Delorie
@ 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
4 siblings, 0 replies; 30+ messages in thread
From: Kalle Olavi Niemitalo @ 2016-10-11 19:35 UTC (permalink / raw)
To: libc-alpha
Siddhesh Poyarekar <siddhesh@sourceware.org> writes:
> +This parameter can also be set for the process at startup by setting the
> +environment variable @code{MALLOC_MMAP_MAX_} to the desired value.
startup.texi has e.g. "@cindex @code{TZ} environment variable".
Could add similar index entries for MALLOC_MMAP_MAX_ and others.
Inconsistently, @vindex is used for the PWD, LANGUAGE, and
COREFILE environment variables.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PING][PATCH 1/2] Add note on MALLOC_MMAP_* environment variables
2016-10-10 17:26 [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables Siddhesh Poyarekar
` (2 preceding siblings ...)
2016-10-11 19:35 ` Kalle Olavi Niemitalo
@ 2016-10-17 14:04 ` Siddhesh Poyarekar
2016-10-17 16:13 ` [PATCH " Carlos O'Donell
4 siblings, 0 replies; 30+ messages in thread
From: Siddhesh Poyarekar @ 2016-10-17 14:04 UTC (permalink / raw)
To: libc-alpha
Ping!
On Monday 10 October 2016 10:56 PM, Siddhesh Poyarekar wrote:
> The mallopt parameters manual does not mention the environment
> variables that can be used to set these parameters at program startup.
> Mention those environment variables for completeness.
>
> * manual/memory.texi: Add environment variable alternatives to
> setting mallopt parameters.
> ---
> manual/memory.texi | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/manual/memory.texi b/manual/memory.texi
> index 5383105..222f126 100644
> --- a/manual/memory.texi
> +++ b/manual/memory.texi
> @@ -1113,12 +1113,18 @@ choices for @var{param}, as defined in @file{malloc.h}, are:
> @item M_MMAP_MAX
> The maximum number of chunks to allocate with @code{mmap}. Setting this
> to zero disables all use of @code{mmap}.
> +
> +This parameter can also be set for the process at startup by setting the
> +environment variable @code{MALLOC_MMAP_MAX_} to the desired value.
> @item M_MMAP_THRESHOLD
> All chunks larger than this value are allocated outside the normal
> heap, using the @code{mmap} system call. This way it is guaranteed
> that the memory for these chunks can be returned to the system on
> @code{free}. Note that requests smaller than this threshold might still
> be allocated via @code{mmap}.
> +
> +This parameter can also be set for the process at startup by setting the
> +environment variable @code{MALLOC_MMAP_THRESHOLD_} to the desired value.
> @comment TODO: @item M_MXFAST
> @item M_PERTURB
> If non-zero, memory blocks are filled with values depending on some
> @@ -1128,16 +1134,25 @@ use of uninitialized or freed heap memory. Note that this option does not
> guarantee that the freed block will have any specific values. It only
> guarantees that the content the block had before it was freed will be
> overwritten.
> +
> +This parameter can also be set for the process at startup by setting the
> +environment variable @code{MALLOC_MMAP_PERTURB_} to the desired value.
> @item M_TOP_PAD
> This parameter determines the amount of extra memory to obtain from the
> system when a call to @code{sbrk} is required. It also specifies the
> number of bytes to retain when shrinking the heap by calling @code{sbrk}
> with a negative argument. This provides the necessary hysteresis in
> heap size such that excessive amounts of system calls can be avoided.
> +
> +This parameter can also be set for the process at startup by setting the
> +environment variable @code{MALLOC_TOP_PAD_} to the desired value.
> @item M_TRIM_THRESHOLD
> This is the minimum size (in bytes) of the top-most, releasable chunk
> that will cause @code{sbrk} to be called with a negative argument in
> order to return memory to the system.
> +
> +This parameter can also be set for the process at startup by setting the
> +environment variable @code{MALLOC_TRIM_THRESHOLD_} to the desired value.
> @end table
>
> @end deftypefun
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables
2016-10-10 17:26 [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables Siddhesh Poyarekar
` (3 preceding siblings ...)
2016-10-17 14:04 ` [PING][PATCH " Siddhesh Poyarekar
@ 2016-10-17 16:13 ` Carlos O'Donell
2016-10-17 16:16 ` Siddhesh Poyarekar
4 siblings, 1 reply; 30+ messages in thread
From: Carlos O'Donell @ 2016-10-17 16:13 UTC (permalink / raw)
To: Siddhesh Poyarekar, libc-alpha
On 10/10/2016 01:26 PM, Siddhesh Poyarekar wrote:
> The mallopt parameters manual does not mention the environment
> variables that can be used to set these parameters at program startup.
> Mention those environment variables for completeness.
Please don't get upset with me :-)
I'm asking you to document the default for these env var tunables.
I think it's valid for users to want to know what value they would have
had if they _didn't_ set the environment variable.
Throwing our hands up in the air and saying "it's implementation defined"
isn't very useful IMO.
> * manual/memory.texi: Add environment variable alternatives to
> setting mallopt parameters.
> ---
> manual/memory.texi | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/manual/memory.texi b/manual/memory.texi
> index 5383105..222f126 100644
> --- a/manual/memory.texi
> +++ b/manual/memory.texi
> @@ -1113,12 +1113,18 @@ choices for @var{param}, as defined in @file{malloc.h}, are:
> @item M_MMAP_MAX
> The maximum number of chunks to allocate with @code{mmap}. Setting this
> to zero disables all use of @code{mmap}.
> +
> +This parameter can also be set for the process at startup by setting the
> +environment variable @code{MALLOC_MMAP_MAX_} to the desired value.
What's the default?
> @item M_MMAP_THRESHOLD
> All chunks larger than this value are allocated outside the normal
> heap, using the @code{mmap} system call. This way it is guaranteed
> that the memory for these chunks can be returned to the system on
> @code{free}. Note that requests smaller than this threshold might still
> be allocated via @code{mmap}.
> +
> +This parameter can also be set for the process at startup by setting the
> +environment variable @code{MALLOC_MMAP_THRESHOLD_} to the desired value.
What's the default?
> @comment TODO: @item M_MXFAST
> @item M_PERTURB
> If non-zero, memory blocks are filled with values depending on some
> @@ -1128,16 +1134,25 @@ use of uninitialized or freed heap memory. Note that this option does not
> guarantee that the freed block will have any specific values. It only
> guarantees that the content the block had before it was freed will be
> overwritten.
> +
> +This parameter can also be set for the process at startup by setting the
> +environment variable @code{MALLOC_MMAP_PERTURB_} to the desired value.
What is the default?
> @item M_TOP_PAD
> This parameter determines the amount of extra memory to obtain from the
> system when a call to @code{sbrk} is required. It also specifies the
> number of bytes to retain when shrinking the heap by calling @code{sbrk}
> with a negative argument. This provides the necessary hysteresis in
> heap size such that excessive amounts of system calls can be avoided.
> +
> +This parameter can also be set for the process at startup by setting the
> +environment variable @code{MALLOC_TOP_PAD_} to the desired value.
What's the default?
> @item M_TRIM_THRESHOLD
> This is the minimum size (in bytes) of the top-most, releasable chunk
> that will cause @code{sbrk} to be called with a negative argument in
> order to return memory to the system.
> +
> +This parameter can also be set for the process at startup by setting the
> +environment variable @code{MALLOC_TRIM_THRESHOLD_} to the desired value.
What's the default? Note: There is a limit even with dynamic trim threshold on.
This disables the dynamic trim threshold, and that's a very important thing to
mention.
> @end table
>
> @end deftypefun
>
--
Cheers,
Carlos.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables
2016-10-17 16:13 ` [PATCH " Carlos O'Donell
@ 2016-10-17 16:16 ` Siddhesh Poyarekar
0 siblings, 0 replies; 30+ messages in thread
From: Siddhesh Poyarekar @ 2016-10-17 16:16 UTC (permalink / raw)
To: Carlos O'Donell, libc-alpha
On Monday 17 October 2016 09:43 PM, Carlos O'Donell wrote:
> On 10/10/2016 01:26 PM, Siddhesh Poyarekar wrote:
>> The mallopt parameters manual does not mention the environment
>> variables that can be used to set these parameters at program startup.
>> Mention those environment variables for completeness.
>
> Please don't get upset with me :-)
Grrr...
> I'm asking you to document the default for these env var tunables.
>
> I think it's valid for users to want to know what value they would have
> had if they _didn't_ set the environment variable.
>
> Throwing our hands up in the air and saying "it's implementation defined"
> isn't very useful IMO.
No I agree that is a good point. I'll work on it based on your comments
on the MALLOC_ARENA_* doc patch, i.e. first describe the GNU allocator
and then use that information to explain the envvars/mallopt params and
also add in defaults.
Siddhesh
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 0/2] Malloc manual cleanups
@ 2016-10-24 14:08 Siddhesh Poyarekar
2016-10-24 14:08 ` [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables Siddhesh Poyarekar
0 siblings, 1 reply; 30+ messages in thread
From: Siddhesh Poyarekar @ 2016-10-24 14:08 UTC (permalink / raw)
To: libc-alpha
Here's take 2 of the cleanup of descriptions in the manual description in
malloc. As suggested in previous review, I have made the following changes:
- Moved up "Efficiency considerations for malloc" into a new subsection called
"The GNU allocator" that gives a high level description of the allocator
design and introduces terms like arenas and chunks. I did not go into too
much detail here and have instead pointed interested readers to the wiki page
DJ wrote.
- Added default values of all of the mallopt parameters
Siddhesh Poyarekar (2):
Add note on MALLOC_MMAP_* environment variables
Document the M_ARENA_* mallopt parameters
malloc/malloc.c | 1 -
manual/memory.texi | 153 ++++++++++++++++++++++++++++++++---------------------
2 files changed, 93 insertions(+), 61 deletions(-)
--
2.7.4
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables
2016-10-24 14:08 [PATCH 0/2] Malloc manual cleanups Siddhesh Poyarekar
@ 2016-10-24 14:08 ` Siddhesh Poyarekar
2016-10-26 4:18 ` Carlos O'Donell
0 siblings, 1 reply; 30+ messages in thread
From: Siddhesh Poyarekar @ 2016-10-24 14:08 UTC (permalink / raw)
To: libc-alpha
The mallopt parameters manual does not mention the environment
variables that can be used to set these parameters at program startup.
Mention those environment variables for completeness.
* manual/memory.texi: Add environment variable alternatives to
setting mallopt parameters.
---
manual/memory.texi | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/manual/memory.texi b/manual/memory.texi
index 5383105..6f33455 100644
--- a/manual/memory.texi
+++ b/manual/memory.texi
@@ -1113,12 +1113,25 @@ choices for @var{param}, as defined in @file{malloc.h}, are:
@item M_MMAP_MAX
The maximum number of chunks to allocate with @code{mmap}. Setting this
to zero disables all use of @code{mmap}.
+
+The default value of this parameter is @code{65536}.
+
+This parameter can also be set for the process at startup by setting the
+environment variable @code{MALLOC_MMAP_MAX_} to the desired value.
@item M_MMAP_THRESHOLD
All chunks larger than this value are allocated outside the normal
heap, using the @code{mmap} system call. This way it is guaranteed
that the memory for these chunks can be returned to the system on
@code{free}. Note that requests smaller than this threshold might still
be allocated via @code{mmap}.
+
+If this parameter is not set, the default value is set as 128 KB and the
+threshold is adjusted dynamically to suit the allocation patterns of the
+program. If the parameter is set, the dynamic adjustment is disabled and the
+value is set statically to the input value.
+
+This parameter can also be set for the process at startup by setting the
+environment variable @code{MALLOC_MMAP_THRESHOLD_} to the desired value.
@comment TODO: @item M_MXFAST
@item M_PERTURB
If non-zero, memory blocks are filled with values depending on some
@@ -1128,16 +1141,34 @@ use of uninitialized or freed heap memory. Note that this option does not
guarantee that the freed block will have any specific values. It only
guarantees that the content the block had before it was freed will be
overwritten.
+
+The default value of this parameter is @code{0}.
+
+This parameter can also be set for the process at startup by setting the
+environment variable @code{MALLOC_MMAP_PERTURB_} to the desired value.
@item M_TOP_PAD
This parameter determines the amount of extra memory to obtain from the
system when a call to @code{sbrk} is required. It also specifies the
number of bytes to retain when shrinking the heap by calling @code{sbrk}
with a negative argument. This provides the necessary hysteresis in
heap size such that excessive amounts of system calls can be avoided.
+
+The default value of this parameter is @code{0}.
+
+This parameter can also be set for the process at startup by setting the
+environment variable @code{MALLOC_TOP_PAD_} to the desired value.
@item M_TRIM_THRESHOLD
This is the minimum size (in bytes) of the top-most, releasable chunk
that will cause @code{sbrk} to be called with a negative argument in
order to return memory to the system.
+
+If this parameter is not set, the default value is set as 128 KB and the
+threshold is adjusted dynamically to suit the allocation patterns of the
+program. If the parameter is set, the dynamic adjustment is disabled and the
+value is set statically to the provided input.
+
+This parameter can also be set for the process at startup by setting the
+environment variable @code{MALLOC_TRIM_THRESHOLD_} to the desired value.
@end table
@end deftypefun
--
2.7.4
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables
2016-10-24 14:08 ` [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables Siddhesh Poyarekar
@ 2016-10-26 4:18 ` Carlos O'Donell
2016-10-26 7:58 ` Michael Kerrisk
` (2 more replies)
0 siblings, 3 replies; 30+ messages in thread
From: Carlos O'Donell @ 2016-10-26 4:18 UTC (permalink / raw)
To: Siddhesh Poyarekar, libc-alpha
On 10/24/2016 10:07 AM, Siddhesh Poyarekar wrote:
> The mallopt parameters manual does not mention the environment
> variables that can be used to set these parameters at program startup.
> Mention those environment variables for completeness.
>
> * manual/memory.texi: Add environment variable alternatives to
> setting mallopt parameters.
Two nits. Otherwise OK.
> ---
> manual/memory.texi | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/manual/memory.texi b/manual/memory.texi
> index 5383105..6f33455 100644
> --- a/manual/memory.texi
> +++ b/manual/memory.texi
> @@ -1113,12 +1113,25 @@ choices for @var{param}, as defined in @file{malloc.h}, are:
> @item M_MMAP_MAX
> The maximum number of chunks to allocate with @code{mmap}. Setting this
> to zero disables all use of @code{mmap}.
> +
> +The default value of this parameter is @code{65536}.
> +
> +This parameter can also be set for the process at startup by setting the
> +environment variable @code{MALLOC_MMAP_MAX_} to the desired value.
> @item M_MMAP_THRESHOLD
> All chunks larger than this value are allocated outside the normal
> heap, using the @code{mmap} system call. This way it is guaranteed
> that the memory for these chunks can be returned to the system on
> @code{free}. Note that requests smaller than this threshold might still
> be allocated via @code{mmap}.
> +
> +If this parameter is not set, the default value is set as 128 KB and the
Should this be 128KiB?
> +threshold is adjusted dynamically to suit the allocation patterns of the
> +program. If the parameter is set, the dynamic adjustment is disabled and the
> +value is set statically to the input value.
> +
> +This parameter can also be set for the process at startup by setting the
> +environment variable @code{MALLOC_MMAP_THRESHOLD_} to the desired value.
> @comment TODO: @item M_MXFAST
> @item M_PERTURB
> If non-zero, memory blocks are filled with values depending on some
> @@ -1128,16 +1141,34 @@ use of uninitialized or freed heap memory. Note that this option does not
> guarantee that the freed block will have any specific values. It only
> guarantees that the content the block had before it was freed will be
> overwritten.
> +
> +The default value of this parameter is @code{0}.
> +
> +This parameter can also be set for the process at startup by setting the
> +environment variable @code{MALLOC_MMAP_PERTURB_} to the desired value.
> @item M_TOP_PAD
> This parameter determines the amount of extra memory to obtain from the
> system when a call to @code{sbrk} is required. It also specifies the
> number of bytes to retain when shrinking the heap by calling @code{sbrk}
> with a negative argument. This provides the necessary hysteresis in
> heap size such that excessive amounts of system calls can be avoided.
> +
> +The default value of this parameter is @code{0}.
> +
> +This parameter can also be set for the process at startup by setting the
> +environment variable @code{MALLOC_TOP_PAD_} to the desired value.
> @item M_TRIM_THRESHOLD
> This is the minimum size (in bytes) of the top-most, releasable chunk
> that will cause @code{sbrk} to be called with a negative argument in
> order to return memory to the system.
> +
> +If this parameter is not set, the default value is set as 128 KB and the
Likewise.
> +threshold is adjusted dynamically to suit the allocation patterns of the
> +program. If the parameter is set, the dynamic adjustment is disabled and the
> +value is set statically to the provided input.
> +
> +This parameter can also be set for the process at startup by setting the
> +environment variable @code{MALLOC_TRIM_THRESHOLD_} to the desired value.
> @end table
>
> @end deftypefun
>
--
Cheers,
Carlos.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables
2016-10-26 4:18 ` Carlos O'Donell
@ 2016-10-26 7:58 ` Michael Kerrisk
2016-10-26 9:47 ` Siddhesh Poyarekar
2016-10-26 11:26 ` Rical Jasan
2 siblings, 0 replies; 30+ messages in thread
From: Michael Kerrisk @ 2016-10-26 7:58 UTC (permalink / raw)
To: Carlos O'Donell
Cc: Siddhesh Poyarekar, libc-alpha, Michael Kerrisk-manpages
I've nothing to add beyond Carlos's comments. I looked this over and
it looks good to me.
Cheers,
Michael
On Wed, Oct 26, 2016 at 6:15 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 10/24/2016 10:07 AM, Siddhesh Poyarekar wrote:
>> The mallopt parameters manual does not mention the environment
>> variables that can be used to set these parameters at program startup.
>> Mention those environment variables for completeness.
>>
>> * manual/memory.texi: Add environment variable alternatives to
>> setting mallopt parameters.
>
> Two nits. Otherwise OK.
>
>> ---
>> manual/memory.texi | 31 +++++++++++++++++++++++++++++++
>> 1 file changed, 31 insertions(+)
>>
>> diff --git a/manual/memory.texi b/manual/memory.texi
>> index 5383105..6f33455 100644
>> --- a/manual/memory.texi
>> +++ b/manual/memory.texi
>> @@ -1113,12 +1113,25 @@ choices for @var{param}, as defined in @file{malloc.h}, are:
>> @item M_MMAP_MAX
>> The maximum number of chunks to allocate with @code{mmap}. Setting this
>> to zero disables all use of @code{mmap}.
>> +
>> +The default value of this parameter is @code{65536}.
>> +
>> +This parameter can also be set for the process at startup by setting the
>> +environment variable @code{MALLOC_MMAP_MAX_} to the desired value.
>> @item M_MMAP_THRESHOLD
>> All chunks larger than this value are allocated outside the normal
>> heap, using the @code{mmap} system call. This way it is guaranteed
>> that the memory for these chunks can be returned to the system on
>> @code{free}. Note that requests smaller than this threshold might still
>> be allocated via @code{mmap}.
>> +
>> +If this parameter is not set, the default value is set as 128 KB and the
>
> Should this be 128KiB?
>
>> +threshold is adjusted dynamically to suit the allocation patterns of the
>> +program. If the parameter is set, the dynamic adjustment is disabled and the
>> +value is set statically to the input value.
>> +
>> +This parameter can also be set for the process at startup by setting the
>> +environment variable @code{MALLOC_MMAP_THRESHOLD_} to the desired value.
>> @comment TODO: @item M_MXFAST
>> @item M_PERTURB
>> If non-zero, memory blocks are filled with values depending on some
>> @@ -1128,16 +1141,34 @@ use of uninitialized or freed heap memory. Note that this option does not
>> guarantee that the freed block will have any specific values. It only
>> guarantees that the content the block had before it was freed will be
>> overwritten.
>> +
>> +The default value of this parameter is @code{0}.
>> +
>> +This parameter can also be set for the process at startup by setting the
>> +environment variable @code{MALLOC_MMAP_PERTURB_} to the desired value.
>> @item M_TOP_PAD
>> This parameter determines the amount of extra memory to obtain from the
>> system when a call to @code{sbrk} is required. It also specifies the
>> number of bytes to retain when shrinking the heap by calling @code{sbrk}
>> with a negative argument. This provides the necessary hysteresis in
>> heap size such that excessive amounts of system calls can be avoided.
>> +
>> +The default value of this parameter is @code{0}.
>> +
>> +This parameter can also be set for the process at startup by setting the
>> +environment variable @code{MALLOC_TOP_PAD_} to the desired value.
>> @item M_TRIM_THRESHOLD
>> This is the minimum size (in bytes) of the top-most, releasable chunk
>> that will cause @code{sbrk} to be called with a negative argument in
>> order to return memory to the system.
>> +
>> +If this parameter is not set, the default value is set as 128 KB and the
>
> Likewise.
>
>> +threshold is adjusted dynamically to suit the allocation patterns of the
>> +program. If the parameter is set, the dynamic adjustment is disabled and the
>> +value is set statically to the provided input.
>> +
>> +This parameter can also be set for the process at startup by setting the
>> +environment variable @code{MALLOC_TRIM_THRESHOLD_} to the desired value.
>> @end table
>>
>> @end deftypefun
>>
>
>
> --
> Cheers,
> Carlos.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables
2016-10-26 4:18 ` Carlos O'Donell
2016-10-26 7:58 ` Michael Kerrisk
@ 2016-10-26 9:47 ` Siddhesh Poyarekar
2016-10-26 11:26 ` Rical Jasan
2 siblings, 0 replies; 30+ messages in thread
From: Siddhesh Poyarekar @ 2016-10-26 9:47 UTC (permalink / raw)
To: Carlos O'Donell, libc-alpha
On Wednesday 26 October 2016 09:45 AM, Carlos O'Donell wrote:
> On 10/24/2016 10:07 AM, Siddhesh Poyarekar wrote:
>> The mallopt parameters manual does not mention the environment
>> variables that can be used to set these parameters at program startup.
>> Mention those environment variables for completeness.
>>
>> * manual/memory.texi: Add environment variable alternatives to
>> setting mallopt parameters.
>
> Two nits. Otherwise OK.
Thanks, pushed.
Siddhesh
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Re: [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables
2016-10-26 4:18 ` Carlos O'Donell
2016-10-26 7:58 ` Michael Kerrisk
2016-10-26 9:47 ` Siddhesh Poyarekar
@ 2016-10-26 11:26 ` Rical Jasan
2016-10-26 11:30 ` Siddhesh Poyarekar
2 siblings, 1 reply; 30+ messages in thread
From: Rical Jasan @ 2016-10-26 11:26 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: Siddhesh Poyarekar, libc-alpha
On 10/25/2016 09:15 PM, Carlos O'Donell wrote:
>> > +If this parameter is not set, the default value is set as 128 KB and the
> Should this be 128KiB?
I don't think binary computers count with 10 fingers. At any rate, we
don't have any ibi's AFAICS:
$ grep -Pi '\d[kmgt]i?b\b' manual/*.texi
So maybe "128kB"? ;)
Rical
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables
2016-10-26 11:26 ` Rical Jasan
@ 2016-10-26 11:30 ` Siddhesh Poyarekar
2016-10-26 12:04 ` Rical Jasan
0 siblings, 1 reply; 30+ messages in thread
From: Siddhesh Poyarekar @ 2016-10-26 11:30 UTC (permalink / raw)
To: Rical Jasan, Carlos O'Donell; +Cc: libc-alpha
On Wednesday 26 October 2016 04:56 PM, Rical Jasan wrote:
> On 10/25/2016 09:15 PM, Carlos O'Donell wrote:
>>>> +If this parameter is not set, the default value is set as 128 KB and the
>> Should this be 128KiB?
>
> I don't think binary computers count with 10 fingers. At any rate, we
> don't have any ibi's AFAICS:
>
> $ grep -Pi '\d[kmgt]i?b\b' manual/*.texi
It's the other way around AFAIK, i.e. KiB == 1024 and KB == 1000. Looks
like there are references to kB in code comments, so I'm fine with
changing it to that, or if you want to be absolutely clear, I could just
make it 131072 bytes ;)
Siddhesh
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables
2016-10-26 11:30 ` Siddhesh Poyarekar
@ 2016-10-26 12:04 ` Rical Jasan
0 siblings, 0 replies; 30+ messages in thread
From: Rical Jasan @ 2016-10-26 12:04 UTC (permalink / raw)
To: siddhesh; +Cc: Carlos O'Donell, libc-alpha
On 10/26/2016 04:30 AM, Siddhesh Poyarekar wrote:
> On Wednesday 26 October 2016 04:56 PM, Rical Jasan wrote:
>> On 10/25/2016 09:15 PM, Carlos O'Donell wrote:
>>>>> +If this parameter is not set, the default value is set as 128 KB and the
>>> Should this be 128KiB?
>>
>> I don't think binary computers count with 10 fingers. At any rate, we
>> don't have any ibi's AFAICS:
>>
>> $ grep -Pi '\d[kmgt]i?b\b' manual/*.texi
>
> It's the other way around AFAIK, i.e. KiB == 1024 and KB == 1000. Looks
> like there are references to kB in code comments, so I'm fine with
> changing it to that, or if you want to be absolutely clear, I could just
> make it 131072 bytes ;)
As unambiguous as possible is best, so if you could fix the 2147483648-
and 4294967296-byte references too, that'd be great. lol
Rical
^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2016-10-26 12:04 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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 1/2] Add note on MALLOC_MMAP_* environment variables Siddhesh Poyarekar
2016-10-26 4:18 ` Carlos O'Donell
2016-10-26 7:58 ` Michael Kerrisk
2016-10-26 9:47 ` Siddhesh Poyarekar
2016-10-26 11:26 ` Rical Jasan
2016-10-26 11:30 ` Siddhesh Poyarekar
2016-10-26 12:04 ` Rical Jasan
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).