summaryrefslogtreecommitdiff
path: root/kernel/user-return-notifier.c
diff options
context:
space:
mode:
authorFrederic Weisbecker <fweisbec@gmail.com>2010-08-22 21:10:35 +0200
committerFrederic Weisbecker <fweisbec@gmail.com>2010-08-22 21:10:35 +0200
commit612d4fd7d0c4a866a531099d4cdd0424c1058321 (patch)
treeae5368c9e39e3f35e23ee3501a6dcf99f35d985c /kernel/user-return-notifier.c
parent6cb8e56161c4103af9178ea45ba61ddbde02969a (diff)
perf: Support for callchains merge
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 <hch@infradead.org> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Paul Mackerras <paulus@samba.org>
Diffstat (limited to 'kernel/user-return-notifier.c')
0 files changed, 0 insertions, 0 deletions