Movatterモバイル変換

This is the mail archive of thelibc-alpha@sourceware.orgmailing list for theglibc project.

malloc trace patch and tools

• From: DJ Delorie <dj at redhat dot com>
• To: libc-alpha at sourceware dot org
• Date: Thu, 24 Aug 2017 13:03:21 -0400
• Subject: malloc trace patch and tools
• Authentication-results: sourceware.org; auth=none
• Authentication-results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
• Authentication-results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=dj at redhat dot com
• Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1AB527ACBA

I've put a patch to insert my trace work from last year (dj/mallocbranch) for the current tree, and a separate tarball of the relatedtools, here:http://people.redhat.com/dj/glibc/The actual tracing happens deep in the malloc code itself.  Theseparate library just enables it, you could (in theory) call the ABIfrom your own app to trace portions.  The trace is designed to be asfast and unobtrusive as possible, since I wanted to preserve therelative timing of different threads as closely as possible (this isthe source of the benchmarks I used for the per-thread cache work).Conversion can happen on a non-trace machine, but should be the samebase arch (ppc vs x86-64) as the captured trace is raw binary innative format.Simulation can happen on any arch as the "workload" format isarch-independent.  I've been collecting workloads in a cache of thingsto benchmark when working on malloc performance.I'm not planning on arguing for inclusion of this work in master justyet.  Carlos and I have talked about tracing options, and feel thatLTTng is probably a more appropriate long-term solution to thatparticular problem.DJ