public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "ben at ben dot com" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sources.redhat.com Subject: [Bug libc/12114] New: Adding priority inheritance to malloc locking Date: Tue, 12 Oct 2010 22:11:00 -0000 [thread overview] Message-ID: <bug-12114-131@http.sourceware.org/bugzilla/> (raw) 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.
next reply other threads:[~2010-10-12 22:11 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-10-12 22:11 ben at ben dot com [this message] 2012-02-21 1:55 ` [Bug malloc/12114] " jsm28 at gcc dot gnu.org 2012-02-22 14:47 ` carlos at systemhalted dot org 2012-02-23 15:05 ` carlos at systemhalted dot org 2014-06-30 7:50 ` fweimer at redhat dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-12114-131@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sources.redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).