summaryrefslogtreecommitdiffstats
path: root/tools/perf/Documentation/perf-trace.txt
diff options
context:
space:
mode:
authorDavid S. Miller <davem@davemloft.net>2010-02-26 12:08:34 -0300
committerIngo Molnar <mingo@elte.hu>2010-02-26 16:28:45 +0100
commit4385d580f2278abab6d336e52522e9a6f5452a11 (patch)
treeab35d78343741a1130b779cd1d98f5ac0041ac37 /tools/perf/Documentation/perf-trace.txt
parentf22f54f4491acd987a6c5a92de52b60ca8b58b61 (diff)
downloadlinux-stable-4385d580f2278abab6d336e52522e9a6f5452a11.tar.gz
linux-stable-4385d580f2278abab6d336e52522e9a6f5452a11.tar.bz2
linux-stable-4385d580f2278abab6d336e52522e9a6f5452a11.zip
perf tools: Flush maps on COMM events
Even though we don't register the counters until the child is right about to exec(), we're still going to get at least a few events while the fork()'d child is still executing 'perf' and in particular we're going to get the MMAP events. We can't distinguish the ones in the newly executed process because the PID will be the same. One way to solve this would be to have a PERF_RECORD_EXEC event, and when this is seen 'perf' can flush it's map cache. We can't use PERF_RECORD_COMM since that's generated by other things, not just exec(). Actually, thinking about it some more, using PERF_RECORD_COMM might be a good enough approximation. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Frédéric Weisbecker <fweisbec@gmail.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Mackerras <paulus@samba.org> LKML-Reference: <1267196914-16238-1-git-send-email-acme@infradead.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Diffstat (limited to 'tools/perf/Documentation/perf-trace.txt')
0 files changed, 0 insertions, 0 deletions