diff options
author | Frederic Weisbecker <fweisbec@gmail.com> | 2010-08-22 23:10:35 +0400 |
---|---|---|
committer | Frederic Weisbecker <fweisbec@gmail.com> | 2010-08-22 23:10:35 +0400 |
commit | 612d4fd7d0c4a866a531099d4cdd0424c1058321 (patch) | |
tree | ae5368c9e39e3f35e23ee3501a6dcf99f35d985c /fs/jbd2/checkpoint.c | |
parent | 6cb8e56161c4103af9178ea45ba61ddbde02969a (diff) | |
download | linux-612d4fd7d0c4a866a531099d4cdd0424c1058321.tar.xz |
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 'fs/jbd2/checkpoint.c')
0 files changed, 0 insertions, 0 deletions