Messages in this thread | | | From | Stephane Eranian <> | Date | Thu, 26 Jan 2017 15:16:08 -0800 | Subject | Re: perf/jit doesn't cope well with mprotect() to jit containing pages |
| |
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
| |