This is the mail archive of the
mailing list for the glibc project.
Re: [patch] mallopt.3: Document M_ARENA_TEST, and M_ARENA_MAX.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>
- Cc: "linux-man at vger dot kernel dot org" <linux-man at vger dot kernel dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 31 Aug 2015 09:20:42 -0400
- Subject: Re: [patch] mallopt.3: Document M_ARENA_TEST, and M_ARENA_MAX.
- Authentication-results: sourceware.org; auth=none
- References: <55DB40AE dot 7080405 at redhat dot com> <55E2F1BD dot 8050609 at gmail dot com>
On 08/30/2015 08:06 AM, Michael Kerrisk (man-pages) wrote:
> diff --git a/man3/mallopt.3 b/man3/mallopt.3
> index c09e801..fd41bf0 100644
> --- a/man3/mallopt.3
> +++ b/man3/mallopt.3
> @@ -66,8 +66,8 @@ and since glibc 2.15 by default.
> In some versions of the allocator there was no limit on the number
> of created arenas (e.g., CentOS 5, RHEL 5).
> -When running programs on newer glibc versions,
> -these applications may exhibit high contention when accessing arenas.
> +When employing newer glibc versions, applications may in
> +some cases exhibit high contention when accessing arenas.
> In these cases, it may be beneficial to increase
> .B M_ARENA_MAX
> to match the number of threads.
> @@ -79,7 +79,7 @@ This is the limit, in number of arenas created, at which the system
> configuration will be examined to evaluate a hard limit on the
> number of created arenas.
> The computed limit is implementation-defined
> -and is usually a multiple of the number of available cores.
> +and is usually a multiple of the number of available CPUs.
I like this. This is better than what I wrote, since a core is not
the right unit here, we are reading /sys/devices/system/cpu/online,
or /proc/stat or /proc/cpuinfo to compute the number of online cpus.
> Once the limit is computed, the result is final and constrains
> the total number of arenas.
Thanks for the commit and fixup!