Sources Bugzilla – Bug 12114
Adding priority inheritance to malloc locking
Last modified: 2012-02-23 15:04:58 UTC
Created attachment 5054 [details]
Patch to add libptmalloc to glibc 2.7, not proposed to directly apply to glibc.
[I circulated this on libc-help with no response.]
I work on a soft realtime system running embedded Linux. We ran into a
problem where high priority threads experienced unexpected delays. One
developer traced a problem to a std::queue operation and from there we
determined that malloc/free (primarily free, due to the way glibc's malloc
works) was showing very high latency jitter.
This was caused by priority inversions when there was malloc arena
contention. We were exacerbating the problem by having several threads
start and initialize at low priority before moving up to their normal
running priority. The thread starts all start over at the first arena
so we were experiencing many more contention events than you would for
long-running threads (though any producer/consumer type operation that
pumps memory between threads would also be subject to this if their
lll_lock is implemented in terms of atomic operations and private futexes,
but it does not use the FUTEX_LOCK_PI idiom. Converting it to do so
would be problematic (I'm happy to discuss my reasoning here, but I will
omit it in this initial description). Instead my solution was to add
another extra-libs library to glibc that builds the regular malloc under
NOT_IN_libc which changes the mapping of __libc_lock to pthreads rather
than lll_lock. Then I enabled PI on the __libc_lock_init calls. This
library can be linked directly or forced with LD_PRELOAD for testing.
I'd welcome any comments on the general topic of PI locking in glibc and
malloc in particular. Also, I started from a state of complete ignorance
about the glibc build, so any review of my attached patch would be helpful.
Here's a description of the patch broken down by major area:
Add libptmalloc to the build:
* nptl/Makefile: Add libptmalloc to extra-libs and add malloc
components to libptmalloc-routines. Use vpath to ../malloc.
* Versions.def: Add libptmalloc stanza with versions referenced
in malloc/Versions, plus 2.2.5 due to nptl/shlib-versions (?)
* nptl/Versions: Add libptmalloc stanza with exports copied from
* nptl/shlib-versions: Copy libpthread stanza to libptmalloc without
understanding it at all. Required to get symbols to bind properly
and versioned .so installation.
Make malloc build outside of libc:
* nptl/Makefile: Add _itoa and itoa-udigits to libptmalloc-routines,
required for mtrace. Could have also exported them from libc as
GLIBC_PRIVATE, but was unsure about namespace issues. Access with
vpath to ../stdio_common.
* nptl/Versions: Add __libc_message, __libc_freeres to libc GLIBC_PRIVATE.
* malloc/malloc.c: If IS_IN_libptmalloc don't remap open, mmap and friends.
* malloc/malloc.c: Change reference to __libc_argv to __progname.
* malloc/mtrace.c: If IS_IN_libptmalloc don't remap setvbuf, fwrite.
* stdio-common/_itoa.c: Extend existing NOT_IN_libc INTUSE fencing
Set PTHREAD_PRIO_INHERIT for NOT_IN_libc __libc_lock_init:
* bits/libc-lock.h: Modify all calls pthread_mutex_init to include
pthread_mutexattr_setprotocol (&attr, PTHREAD_PRIO_INHERIT). This
only affects defines that are fenced for NOT_IN_libc already but it
does affect all extra-libs __libc_lock users (to include the new
libptmalloc, which is the main goal).
The symbol versioning of pthread_mutexattr_setprotocol may be wrong
because there is no __pthread_mutexattr_setprotocol and maybe I
should have made one?
Are you still interested in discussing this issue about PI and malloc?
I'd be interested in hearing your reasoning for not turning on PI in the default malloc provided by glibc?