[Bug libc/1541] New: Poor threaded application performance when using malloc

["sjmunroe at us dot ibm dot com" <sourceware-bugzilla at sourceware dot org>]

Threaded applications that use malloc to allocate large buffer/work ares will
suffer significant performance degradation when ever the allocation size exceeds
the MMAP_THRESHOLD.

When a malloc allocation size exceeds the MMAP_THRESHOLD the storage is
allocated via anonymous mmap insted of from brt storage. The mmap syscal only
allocate the region, no pages are allocated until 1st touch. So there is page
fault for each page as it is touched for the 1st time. The kernel has a
semaphore around the "allocate zeroed page" operation which seriallizes this
operation for threaded applications. These anonymous mmap regions are not resued
by malloc so the "fault/zero page" bottleneck is ocurrs for every large allocation.

This can be seen as a kernel problem but it is also a glibc problem because for
some application the default MMAP_THRESHOLD (normally 128K) is simply too small.
Changing the MMAP_THRESHOLD to a value large enough to handle most allocations
gives a signicant speed up. 

For 64-bit platforms it could be wise to bump up the default thresholds to a
more reasonable value (say 16M). Or we need a simple and effective way to change
the thresholds from outside the applications. The mallopt API can used used to
change the default MMAP_THRESHOLD but many customers are reluctant to change
their source "just for Linux". And enviroment varible based mechansim may be
more acceptable.

-- 
           Summary: Poor threaded application performance when using malloc
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: sjmunroe at us dot ibm dot com
                CC: glibc-bugs at sources dot redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=1541

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.