On Thu, Jan 26, 2017 at 2:19 PM, Peter Zijlstra <pet...@infradead.org> wrote: > On Thu, Jan 26, 2017 at 01:00:52PM -0800, Andres Freund wrote: >> The problem is that (quoted below) without that hack the subsequent >> mmaps just expand the previous VMAs which leads to perf loosing its >> (address,range) -> symbol mappings for previously (in the same expanded >> range) known symbols. > > I'm assuming this is the userspace tool doing that, right? > > Acme, is that something we can cure? Instead of throwing away eveything > known of the previous map, merge them when they grow? > > So I think the problem was that we don't track munmap(), so if you see > two overlapping mappings, we have no clue and assume an munmap() has > happened or something. I can't really remember, its been many many years > since I wrote all that :-(
But perf report takes care of overlapping mmaps normally, see util/map.c:map_groups__fixup_overlappings VMA merging does not change anything at the user level. The kernel will see two mmaps and so will perf record and perf report. This is what you have. In the samples I quoted from your example, this is what should happen. If it does not then there is something wrong in perf report. In the case of Java, if I recall, there is a single large mmap for the code cache and it works fine.
