kernel.git/tools/perf/util/callchain.c, branch linux-3.6.y

perf callchain: Make callchain cursors TLS

2012-05-31T13:47:12Z

perf top -G has a race on callchain cursor between main thread and display thread. Since the callchain cursors are used locally make them thread-local data would solve the problem. Signed-off-by: Namhyung Kim Reported-by: Sunjin Yang Suggested-by: Arnaldo Carvalho de Melo Cc: Ingo Molnar Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Sunjin Yang Link: http://lkml.kernel.org/r/1338443007-24857-1-git-send-email-namhyung.kim@lge.com Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Kill event_t typedef, use 'union perf_event' instead

2011-01-29T18:25:37Z

And move the event_t methods to the perf_event__ too. No code changes, just namespace consistency. Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Mike Galbraith Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Tom Zanussi LKML-Reference: Signed-off-by: Arnaldo Carvalho de Melo

perf callchain: Don't give arbitrary gender to callchain tree nodes

2011-01-22T21:56:31Z

Some little callchain tree nodes shyly asked me if they can have sisters. How cute! Cc: Ingo Molnar Cc: Paul Mackerras Cc: Peter Zijlstra LKML-Reference: <1294977121-5700-5-git-send-email-fweisbec@gmail.com> Signed-off-by: Frederic Weisbecker Signed-off-by: Arnaldo Carvalho de Melo

perf callchain: Rename register_callchain_param into callchain_register_param

2011-01-22T21:56:31Z

To make the callchain API naming more consistent. Cc: Ingo Molnar Cc: Paul Mackerras Cc: Peter Zijlstra LKML-Reference: <1294977121-5700-4-git-send-email-fweisbec@gmail.com> Signed-off-by: Frederic Weisbecker Signed-off-by: Arnaldo Carvalho de Melo

perf callchain: Rename cumul_hits into callchain_cumul_hits

2011-01-22T21:56:31Z

That makes the callchain API naming more consistent and reduce potential naming clashes. Cc: Ingo Molnar Cc: Paul Mackerras Cc: Peter Zijlstra LKML-Reference: <1294977121-5700-3-git-send-email-fweisbec@gmail.com> Signed-off-by: Frederic Weisbecker Signed-off-by: Arnaldo Carvalho de Melo

perf callchain: Feed callchains into a cursor

2011-01-22T21:56:31Z

The callchains are fed with an array of a fixed size. As a result we iterate over each callchains three times: - 1st to resolve symbols - 2nd to filter out context boundaries - 3rd for the insertion into the tree This also involves some pairs of memory allocation/deallocation everytime we insert a callchain, for the filtered out array of addresses and for the array of symbols that comes along. Instead, feed the callchains through a linked list with persistent allocations. It brings several pros like: - Merge the 1st and 2nd iterations in one. That was possible before but in a way that would involve allocating an array slightly taller than necessary because we don't know in advance the number of context boundaries to filter out. - Much lesser allocations/deallocations. The linked list keeps persistent empty entries for the next usages and is extendable at will. - Makes it easier for multiple sources of callchains to feed a stacktrace together. This is deemed to pave the way for cfi based callchains wherein traditional frame pointer based kernel stacktraces will precede cfi based user ones, producing an overall callchain which size is hardly predictable. This requirement makes the static array obsolete and makes a linked list based iterator a much more flexible fit. Basic testing on a big perf file containing callchains (~ 176 MB) has shown a throughput gain of about 11% with perf report. Cc: Ingo Molnar Cc: Paul Mackerras Cc: Peter Zijlstra LKML-Reference: <1294977121-5700-2-git-send-email-fweisbec@gmail.com> Signed-off-by: Frederic Weisbecker Signed-off-by: Arnaldo Carvalho de Melo

perf: Support for callchains merge

2010-08-22T19:10:35Z

If we sort the histograms by comm, which is the default, we need to merge some of them, typically different thread histograms of a same process, or just same comm. But during this merge, we forgot to merge callchains. So imagine we have three threads (tids: 1000, 1001, 1002) that belong to comm "foo". tid 1000 got 100 events tid 1001 got 10 events tid 1002 got 3 events Once we merge these histograms to get a per comm result, we'll finally get: "foo" got 113 events The problem is if we merge 1000 and 1001 histograms into 1002, then the end merge result, wrt callchains, will be only callchains that belong to 1002. This is because we haven't handled callchains in the merge. Only those from one of the threads inside a common comm survive. It means during this merge, we can lose a lot of callchains. Fix this by implementing callchains merge and apply it on histograms that collapse. Reported-by: Christoph Hellwig Signed-off-by: Frederic Weisbecker Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: Paul Mackerras

perf: Rename append_callchain into callchain_append

2010-08-22T18:43:51Z

Do that to start a consistant callchain API namespace. Signed-off-by: Frederic Weisbecker Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: Paul Mackerras Cc: Christoph Hellwig

perf: Keep track of the max depth of a callchain

2010-08-22T18:43:17Z

In order to implement callchains collapsing, we need to keep track of the maximum depth in a histogram tree of callchains. This way we'll avoid allocating an arbitrary temporary buffer size on callchain merge time. Signed-off-by: Frederic Weisbecker Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: Paul Mackerras Cc: Christoph Hellwig

Merge branch 'linus' into perf/core

2010-07-21T19:43:06Z

Merge reason: Pick up the latest perf fixes. Signed-off-by: Ingo Molnar