From: Peter Zijlstra <peterz@infradead.org>
To: Andres Freund <andres@anarazel.de>
Cc: eranian@gmail.com, LKML <linux-kernel@vger.kernel.org>,
Stephane Eranian <eranian@google.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Jiri Olsa <jolsa@redhat.com>, Ingo Molnar <mingo@elte.hu>,
anton@ozlabs.org, Namhyung Kim <namhyung@kernel.org>
Subject: Re: perf/jit doesn't cope well with mprotect() to jit containing pages
Date: Thu, 26 Jan 2017 23:19:12 +0100 [thread overview]
Message-ID: <20170126221912.GF6515@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20170126210052.3znejq6s4ah3l2ow@alap3.anarazel.de>
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 :-(
next prev parent reply other threads:[~2017-01-26 22:19 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-10 5:02 perf/jit doesn't cope well with mprotect() to jit containing pages Andres Freund
2016-12-12 8:49 ` Peter Zijlstra
2016-12-12 9:01 ` Andres Freund
2016-12-12 9:28 ` Peter Zijlstra
2017-01-26 1:25 ` Andres Freund
2017-01-26 22:15 ` Peter Zijlstra
2017-01-26 23:04 ` Andres Freund
2017-01-30 11:52 ` [tip:perf/core] perf/core: Fix PERF_RECORD_MMAP2 prot/flags for anonymous memory tip-bot for Peter Zijlstra
2017-01-26 20:32 ` perf/jit doesn't cope well with mprotect() to jit containing pages Stephane Eranian
2017-01-26 21:00 ` Andres Freund
2017-01-26 21:17 ` Stephane Eranian
2017-01-26 21:22 ` Andres Freund
2017-01-26 21:34 ` Stephane Eranian
2017-01-26 21:51 ` Andres Freund
2017-01-26 22:19 ` Peter Zijlstra [this message]
2017-01-26 22:26 ` Stephane Eranian
2017-01-26 22:38 ` Andres Freund
2017-01-26 22:51 ` Stephane Eranian
2017-01-26 23:09 ` Andres Freund
2017-01-26 23:16 ` Stephane Eranian
2017-01-27 13:07 ` Peter Zijlstra
2017-01-27 15:43 ` Arnaldo Carvalho de Melo
2017-01-27 17:35 ` Stephane Eranian
2017-01-27 17:38 ` [PATCH] handle munmap records in tools/perf was: " Arnaldo Carvalho de Melo
2017-01-27 17:46 ` Stephane Eranian
2017-01-27 18:05 ` Arnaldo Carvalho de Melo
2017-01-27 18:10 ` Stephane Eranian
2017-01-27 19:18 ` Arnaldo Carvalho de Melo
2017-01-27 19:26 ` Stephane Eranian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170126221912.GF6515@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=acme@kernel.org \
--cc=andres@anarazel.de \
--cc=anton@ozlabs.org \
--cc=eranian@gmail.com \
--cc=eranian@google.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=namhyung@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox