>> ** Implemented solution >> >> This patch solves the issue by removing // anon mmap events for any >> process which has a valid jit-<pid>.dump file. >> >> It tracks on a per process basis to handle the case where some running >> apps support jit-<pid>.dump, but some only support perf-<pid>.map. >> >> It adds new assumptions: >> * // anon mmap events are only required for perf-<pid>.map support. >> * An app that uses jit-<pid>.dump, no longer needs perf-<pid>.map >> support. It assumes that any perf-<pid>.map info is inferior. >> >> *** Details >> >> Use thread->priv to store whether a jitdump file has been processed >> >> During "perf inject --jit", discard "//anon*" mmap events for any pid >> which has sucessfully processed a jitdump file. > > > Thanks Steve this is an important fix! As //anon could be for malloc or other > uses, should the stripping behavior be behind a flag? > > Ian
I hadn't anticipated a need to preserve the //anon mmap events when profiling JIT generated code. As far as I know mmap events are captured by perf only for mapping code to symbols. File mappings are kept by the change. Only // anon mappings are stripped. (Only for processes which emitted jitdump files.) And these are stripped only during the `perf inject --jit` step. I believe the // Anon mapping are only generally useful for mapping JIT code. I suppose if someone was trying to count mmap events it might be confusing, but `perf inject --jit` creates synthetic mmap file events which would also make this scenario confusing. I personally don't see a good reason to add a flag. I also don't see a simple way either. Not running `perf inject --jit` would preserve existing behavior w/o jitdump support. Without stripping the anon events jitdump support is painfully broken....
