Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1567795

Re: perf/jit doesn't cope well with mprotect() to jit containing pages

Show all headers | View raw

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

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: perf/jit doesn't cope well with mprotect() to jit containing pages Stephane Eranian <eranian@googlemail.com> - 2017-01-26 21:50 +0100
  Re: perf/jit doesn't cope well with mprotect() to jit containing  pages Andres Freund <andres@anarazel.de> - 2017-01-26 22:10 +0100
    Re: perf/jit doesn't cope well with mprotect() to jit containing pages Stephane Eranian <eranian@google.com> - 2017-01-26 22:20 +0100
      Re: perf/jit doesn't cope well with mprotect() to jit containing  pages Andres Freund <andres@anarazel.de> - 2017-01-26 22:30 +0100
        Re: perf/jit doesn't cope well with mprotect() to jit containing pages Stephane Eranian <eranian@google.com> - 2017-01-26 22:40 +0100
          Re: perf/jit doesn't cope well with mprotect() to jit containing  pages Andres Freund <andres@anarazel.de> - 2017-01-26 23:00 +0100
    Re: perf/jit doesn't cope well with mprotect() to jit containing  pages Peter Zijlstra <peterz@infradead.org> - 2017-01-26 23:20 +0100
      Re: perf/jit doesn't cope well with mprotect() to jit containing pages Stephane Eranian <eranian@google.com> - 2017-01-26 23:30 +0100
        Re: perf/jit doesn't cope well with mprotect() to jit containing  pages Andres Freund <andres@anarazel.de> - 2017-01-26 23:40 +0100
          Re: perf/jit doesn't cope well with mprotect() to jit containing pages Stephane Eranian <eranian@google.com> - 2017-01-27 00:00 +0100
            Re: perf/jit doesn't cope well with mprotect() to jit containing  pages Andres Freund <andres@anarazel.de> - 2017-01-27 00:20 +0100
              Re: perf/jit doesn't cope well with mprotect() to jit containing pages Stephane Eranian <eranian@google.com> - 2017-01-27 00:20 +0100
                Re: perf/jit doesn't cope well with mprotect() to jit containing  pages Peter Zijlstra <peterz@infradead.org> - 2017-01-27 14:10 +0100
                Re: perf/jit doesn't cope well with mprotect() to jit containing  pages Arnaldo Carvalho de Melo <acme@kernel.org> - 2017-01-27 16:50 +0100
                Re: perf/jit doesn't cope well with mprotect() to jit containing pages Stephane Eranian <eranian@google.com> - 2017-01-27 18:40 +0100
                [PATCH] handle munmap records in tools/perf was: Re: perf/jit  doesn't cope well with mprotect() to jit containing pages Arnaldo Carvalho de Melo <acme@kernel.org> - 2017-01-27 18:50 +0100
                Re: [PATCH] handle munmap records in tools/perf was: Re: perf/jit  doesn't cope well with mprotect() to jit containing pages Stephane Eranian <eranian@googlemail.com> - 2017-01-27 19:00 +0100
                Re: [PATCH] handle munmap records in tools/perf was: Re: perf/jit  doesn't cope well with mprotect() to jit containing pages Stephane Eranian <eranian@googlemail.com> - 2017-01-27 19:20 +0100
                Re: [PATCH] handle munmap records in tools/perf was: Re: perf/jit  doesn't cope well with mprotect() to jit containing pages Arnaldo Carvalho de Melo <acme@kernel.org> - 2017-01-27 20:30 +0100
                Re: [PATCH] handle munmap records in tools/perf was: Re: perf/jit  doesn't cope well with mprotect() to jit containing pages Stephane Eranian <eranian@googlemail.com> - 2017-01-27 20:40 +0100
                Re: [PATCH] handle munmap records in tools/perf was: Re: perf/jit  doesn't cope well with mprotect() to jit containing pages Arnaldo Carvalho de Melo <acme@kernel.org> - 2017-01-27 19:40 +0100

csiph-web