* malloc trace patch and tools
@ 2017-08-24 17:03 DJ Delorie
0 siblings, 0 replies; only message in thread
From: DJ Delorie @ 2017-08-24 17:03 UTC (permalink / raw)
To: libc-alpha
I've put a patch to insert my trace work from last year (dj/malloc
branch) for the current tree, and a separate tarball of the related
tools, here:
http://people.redhat.com/dj/glibc/
The actual tracing happens deep in the malloc code itself. The
separate library just enables it, you could (in theory) call the ABI
from your own app to trace portions. The trace is designed to be as
fast and unobtrusive as possible, since I wanted to preserve the
relative timing of different threads as closely as possible (this is
the source of the benchmarks I used for the per-thread cache work).
Conversion can happen on a non-trace machine, but should be the same
base arch (ppc vs x86-64) as the captured trace is raw binary in
native format.
Simulation can happen on any arch as the "workload" format is
arch-independent. I've been collecting workloads in a cache of things
to benchmark when working on malloc performance.
I'm not planning on arguing for inclusion of this work in master just
yet. Carlos and I have talked about tracing options, and feel that
LTTng is probably a more appropriate long-term solution to that
particular problem.
DJ
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2017-08-24 17:03 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-08-24 17:03 malloc trace patch and tools DJ Delorie
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).