On 31 August 2015 at 15:20, Carlos O'Donell <carlos@xxxxxxxxxx> wrote: > 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. > > OK. > >> 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. >> See > > Thanks for the commit and fixup! Thanks for checking the changes, Carlos! Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
