From: David Mosberger <davidm@napali.hpl.hp.com>
To: libc-hacker@sources.redhat.com
Cc: davidm@napali.hpl.hp.com
Subject: second thoughts on using dl_iterate_phdr() for cache-validation
Date: Wed, 31 Mar 2004 08:53:00 -0000 [thread overview]
Message-ID: <16490.8972.453326.222897@napali.hpl.hp.com> (raw)
Doing some more careful performance analysis with libunwind, I'm
finding that the dl_iterate_phdr() call needed to verify that the
phdr-list didn't change is rather expensive. Specifically, the time
needed to initialize an "unwind cursor" (via unw_init_local()) is as
follows:
without dl_iterate_phdr() callback (unsafe): 140 ns
with dl_iterate_phdr(), without -lpthread: 200 ns
with dl_iterate_phdr(), with -lpthread: 300 ns
This is rather more than I expected and a slow-down of more than a
factor of 2 for multi-threaded apps is bit more than I'm willing to
bear since it could really affect the usability of libunwind for
things such as allocation tracking or stack-trace-based sampling.
The profile for the "without -lpthread" case looks like this:
% time self cumul calls self/call tot/call name
60.44 13.05 13.05 101M 129n 204n _ULia64_init_local
17.19 3.71 16.76 99.6M 37.3n 66.7n dl_iterate_phdr
4.65 1.00 17.76 101M 9.97n 9.97n rtld_lock_default_lock_recursive
4.64 1.00 18.77 99.0M 10.1n 10.1n rtld_lock_default_unlock_recursive
The profile for the "with -lpthread" case looks like this (this was
measured on a different machine, so the total time of 223 ns is not
comparable to the 300 ns mentioned above; the relative times are fine,
though):
% time self cumul calls self/call tot/call name
47.93 11.25 11.25 99.6M 113n 223n _ULia64_init_local
18.35 4.31 15.56 100M 43.0n 43.0n pthread_mutex_lock
11.81 2.77 18.33 100M 27.7n 27.7n __pthread_mutex_unlock_usercnt
11.65 2.73 21.06 100M 27.3n 103n __GI___dl_iterate_phdr
For brevity, I didn't include the call-graphs, but they are pretty
easy: all calls to dl_iterate_phdr() are indirectly due to the
cache-validation done by _ULia64_init_local() and almost all
lock-related calls are due to dl_iterate_phdr().
I suppose I could add a libunwind-hack to disable cache-validation,
but that seems like a step backward since it would make caching unsafe
again.
In case it matters, the first profile was obtained with libc v2.3.2
and the second profile was obtained with the CVS libc (as of a few
days ago).
Can this be improved?
--david
next reply other threads:[~2004-03-31 1:46 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-31 8:53 David Mosberger [this message]
2004-03-31 16:04 ` Roland McGrath
2004-04-01 2:33 ` David Mosberger
2004-11-04 23:41 ` David Mosberger
2004-11-04 23:53 ` Roland McGrath
2004-11-05 0:40 ` David Mosberger
2004-11-05 1:10 ` Roland McGrath
2004-11-05 1:28 ` David Mosberger
2004-11-05 1:36 ` Roland McGrath
2004-11-05 2:09 ` David Mosberger
2004-11-05 3:27 ` Roland McGrath
2004-11-06 0:21 ` David Mosberger
2004-11-06 2:32 ` Roland McGrath
2004-11-09 0:15 ` David Mosberger
2004-11-09 4:40 ` Roland McGrath
2004-11-10 5:40 ` David Mosberger
2004-11-10 20:36 ` David Mosberger
2004-11-10 20:45 ` Roland McGrath
2004-11-11 6:17 ` David Mosberger
2004-11-11 22:24 ` Roland McGrath
2004-11-12 19:32 ` David Mosberger
2004-04-15 18:28 David Mosberger
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=16490.8972.453326.222897@napali.hpl.hp.com \
--to=davidm@napali.hpl.hp.com \
--cc=davidm@hpl.hp.com \
--cc=libc-hacker@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: link
Be 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).