From: David Miller <da...@davemloft.net> 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 > header->misc. > > 2) Use this to elide the map groups clone in > thread__clone_map_groups(). Looking into code history, I notice: commit 363b785f3805a2632eb09a8b430842461c21a640 Author: Don Zickus <dzic...@redhat.com> Date: Fri Mar 14 10:43:44 2014 -0400 perf tools: Speed up thread map generation and the subsequent: commit 4aa5f4f7bb8bc41cba15bcd0d80c4fb085027d6b Author: Arnaldo Carvalho de Melo <a...@redhat.com> 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 the parent. 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) { ... thread__clone_map_groups(thread, parent) { ... map_groups__clone(thread, parent->mg) 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. Thanks.