[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170126230956.srv2wtlwhwihgn32@alap3.anarazel.de>
Date: Thu, 26 Jan 2017 15:09:56 -0800
From: Andres Freund <andres@...razel.de>
To: Stephane Eranian <eranian@...gle.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
"eranian@...il.com" <eranian@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Jiri Olsa <jolsa@...hat.com>, Ingo Molnar <mingo@...e.hu>,
Anton Blanchard <anton@...abs.org>,
Namhyung Kim <namhyung@...nel.org>
Subject: Re: perf/jit doesn't cope well with mprotect() to jit containing
pages
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).
> 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
Powered by blists - more mailing lists