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 priorities differ). 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 malloc/Versions. * 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[0] 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 for _itoa_*_digits. 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?
Ben, 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? Cheers, Carlos.