From: Stephane Eranian <eranian@google.com>
To: Andres Freund <andres@anarazel.de>
Cc: Peter Zijlstra <peterz@infradead.org>,
"eranian@gmail.com" <eranian@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Jiri Olsa <jolsa@redhat.com>, Ingo Molnar <mingo@elte.hu>,
Anton Blanchard <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 15:16:08 -0800 [thread overview]
Message-ID: <CABPqkBQq-33ky_uZ4UgaFZaA-4=uuR2cRrAzcT5DabCZ_H30FA@mail.gmail.com> (raw)
In-Reply-To: <20170126230956.srv2wtlwhwihgn32@alap3.anarazel.de>
On Thu, Jan 26, 2017 at 3:09 PM, Andres Freund <andres@anarazel.de> wrote:
> Hi Stephane,
>
>
> On 2017-01-26 14:51:02 -0800, Stephane Eranian wrote:
>> Ok, I think I see the problem now (sorry was slow....):
>
> No worries ;)
>
>
>> the timeline is as follows as seen from the user in your case:
>>
>> T0: mmap(0x1000) for func1()
>> T1 mmap(0x2000) for func1();
>> T3: jit emits info func1() [0x1000-0x1fff]
>> T4: mmap(0x3000) for func2()
>> T5: mmap(0x4000) for funcs2()
>> T6: jit emits info for func2() [0x2000-0x3fff]
>>
>> But the problem is that each mmap covers existing mmaps and thus
>> supersedes the others as per the time stamp.
>
> Yes, I think that's whats happening. Not that I actually know what I'm
> talking about here :)
>
>
>> The problem is not specific to jit, it just reveals itself in your case.
>>
>> The logic in perf is that a more recent mmap supersedes an older one,
>> so you have:
>> T3: 0x1000-0x2000 owned by func1
>> T4: 0x1000-0x3000 owned by anon
>> T5: 0x1000-0x4000 owned by anon
>> T6: 0x1000-0x4000 owned partially by func2()
>>
>> And thus perf cannot symbolize func1() anymore because it has nothing
>> mapped in 0x1000-0x1fff but anon.
>>
>> Did I get the problem right this time?
>
> Yep.
>
>
>> This is tricky to solve here because the tool does not know about the
>> merging of the VMAs and assume you are overlapping mmaps and not
>> merging them.
>
> Yea, it looked tricky. I'd looked around and the only solutions I'd
> found was filtering out the anon mappings (obviously not a real
> solution) or preventing the merging (not a real solution either).
>
One solution would be for the kernel to report actual mmaps and not resulting
VMA layouts. Is that case you would have your 4 mmaps each reporting 4kb.
That means the perf hook in the mmap code would have to be placed somewhere
else. I don't know how feasible this is. I will let Peter comment on this. But
hopefully by now, I have described the problem clearly enough that we can work
out a solution.
>
>> Again the problem is not specific to jit, merging of VMA can happen
>> anytime with any app.
>
> Sorry if I hinted in the wrong direction - I didn't see any other bad
> consequences. I guess in most other cases with merged VMAs its
> relatively harmless, since it'll presumably mostly be memory allocations
> and such, where this wont matter.
>
> Greetings,
>
> Andres Freund
next prev parent reply other threads:[~2017-01-26 23:16 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
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 [this message]
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='CABPqkBQq-33ky_uZ4UgaFZaA-4=uuR2cRrAzcT5DabCZ_H30FA@mail.gmail.com' \
--to=eranian@google.com \
--cc=acme@kernel.org \
--cc=andres@anarazel.de \
--cc=anton@ozlabs.org \
--cc=eranian@gmail.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.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;
as well as URLs for NNTP newsgroup(s).