[Bug libc/12114] New: Adding priority inheritance to malloc locking

["ben at ben dot com" <sourceware-bugzilla at sourceware dot org>]

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

           Summary: Adding priority inheritance to malloc locking
           Product: glibc
           Version: 2.8
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper.fsp@gmail.com
        ReportedBy: ben@ben.com


Created attachment 5054
  --> http://sourceware.org/bugzilla/attachment.cgi?id=5054
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?

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.