Re: perf overlapping maps...
From: David Miller
Date: Sat Oct 20 2018 - 00:51:30 EST
From: David Miller <davem@xxxxxxxxxxxxx>
Date: Fri, 19 Oct 2018 21:05:49 -0700 (PDT)
> One solution I've come up with is:
> 1) When synthesizing a fork event, set PERF_RECORD_MISC_COMM_EXEC in
> 2) Use this to elide the map groups clone in
Looking into code history, I notice:
Author: Don Zickus <dzickus@xxxxxxxxxx>
Date: Fri Mar 14 10:43:44 2014 -0400
perf tools: Speed up thread map generation
and the subsequent:
Author: Arnaldo Carvalho de Melo <acme@xxxxxxxxxx>
Date: Fri Feb 27 19:52:10 2015 -0300
perf tools: Fix FORK after COMM when synthesizing records for pre-existing threads
If Don wanted to have the map cloning to happen for processes without
CLONE_VM, I'm not sure that's right.
For real threads, we just take a reference to the map group from
Don, a quick summary. If we synthesize a fork event, let's say for an
emacs process. perf will clone the map groups of the parent bash
shell which invoked emacs. Via:
thread__fork(thread, parent, timestamp)
Which is completely bogus. It brings all of the bash process maps
into the emacs thread map group. Then we process the emacs mmap2
events, which overlap the bash process maps already cloned into the
emacs map group. And this make all kinds of erroneous things happen.
I'm suggesting to elide the map groups clone in this situation where
we are synthesizing the fork.