Messages in this thread | | | From | Steve MacLean <> | Subject | RE: [PATCH v3] perf inject --jit: Remove //anon mmap events | Date | Mon, 11 Nov 2019 21:35:56 +0000 |
| |
> > > > While a JIT is jitting code it will eventually need to commit more > > > > pages and change these pages to executable permissions. > > > > > > > > Typically the JIT will want these colocated to minimize branch displacements. > > > > > > > > The kernel will coalesce these anonymous mapping with identical > > > > permissions before sending an MMAP event for the new pages. This > > > > means the mmap event for the new pages will include the older pages. > > > > > > > > These anonymous mmap events will obscure the jitdump injected pseudo events. > > > > This means that the jitdump generated symbols, machine code, > > > > debugging info, and unwind info will no longer be used. > > > > > > > > Observations: > > > > > > > > When a process emits a jit dump marker and a jitdump file, the > > > > perf-xxx.map file represents inferior information which has been > > > > superceded by the jitdump jit-xxx.dump file. > > > > > > > > Further the '//anon*' mmap events are only required for the legacy > > > > perf-xxx.map mapping. > > > > > > > > When attaching to an existing process, the synthetic anon map > > > > events are given a time stamp of -1. These should not obscure the > > > > jitdump events which have an actual time. > > > > > > > > Summary: > > > > > > > > Use thread->priv to store whether a jitdump file has been > > > > processed > > > > > > I'm ok wih the implementation but not sure about the described JIT/mmap logic, Stephane? > > > > > > jirka > > > > The kernel only seems to coalesce the anonymous mappings when the allocations grow beyond 64K. It may not affect JITs for smaller sets of JITted code. I would guess a javascript JIT engine might not hit this type of problem often. > > > > @Stephane Eranian could you comment. > > > > @Jiri Olsa I am happy to expand the explanation if it would be helpful. > > that'd be great, thanks > > jirka >
Here is an expanded description in markdown syntax. If you need additional or different details let me know.
## perf-<pid>.map and jit-<pid>.dump designs:
When a JIT generates code to be executed, it must allocate memory and mark it executable using an mmap call.
### perf-<pid>.map design
The perf-<pid>.map assumes that any sample recorded in an anonymous memory page is JIT code. It then tries to resolve the symbol name by looking at the process' perf-<pid>.map.
### jit-<pid>.dump design
The jit-<pid>.dump mechanism takes a different approach. It requires a JIT to write a `<path>/jit-<pid>.dump` file. This file must also be mmapped so that perf inject -jit can find the file. The JIT must also add JIT_CODE_LOAD records for any functions it generates. The records are timestamped using a clock which can be correlated to the perf record clock.
After perf record, the `perf inject -jit` pass parses the recording looking for a `<path>/jit-<pid>.dump` file. When it finds the file, it parses it and for each JIT_CODE_LOAD record: * creates an elf file `<path>/jitted-<pid>-<code_index>.so * injects a new mmap record mapping the new elf file into the process.
### Coexistence design
The kernel and perf support both of these mechanisms. We need to make sure perf works on an app supporting either or both of these mechanisms.
Both designs rely on mmap records to determine how to resolve an ip address.
The mmap records of both techniques by definition overlap. When the JIT compiles a method, it must: * allocate memory (mmap) * add execution privilege (mprotect or mmap. either will generate an mmap event form the kernel to perf) * compile code into memory * add a function record to perf-<pid>.map and/or jit-<pid>.dump
Because the jit-<pid>.dump mechanism supports greater capabilities, perf prefers the symbols from jit-<pid>.dump. It implements this based on timestamp ordering of events. There is an implicit ASSUMPTION that the JIT_CODE_LOAD record timestamp will be after the // anon mmap event that was generated during memory allocation or adding the execution privilege setting.
## Problems with the ASSUMPTION
The ASSUMPTION made in the Coexistence design section above is violated in the following scenario.
### Scenario
While a JIT is jitting code it will eventually need to commit more pages and change these pages to executable permissions. Typically the JIT will want these collocated to minimize branch displacements.
The kernel will coalesce these anonymous mapping with identical permissions before sending an MMAP event for the new pages. The address range of the new mmap will not be just the most recently mmap pages.
### Symptoms
The coalesced // anon mmap event will be timestamped after the JIT_CODE_LOAD records. This means it will be used as the most recent mapping for that entire address range. For remaining events it will look at the inferior perf-<pid>.map for symbols.
If both mechanisms are supported, the symbol will appear twice with different module names. This causes weird behavior in reporting.
If only jit-<pid>.dump is supported, the symbol will no longer be resolved.
## Proposed solution
This patch solves the issue by removing // anon mmap events for any process which has a valid jit-<pid>.dump file.
It tracks on a per process basis to handle the case where some running apps support jit-<pid>.dump, but some only support perf-<pid>.map.
It adds new assumptions: * // anon mmap events are only required for perf-<pid>.map support. * An app that uses jit-<pid>.dump, no longer needs perf-<pid>.map support. It assumes that any perf-<pid>.map info is inferior.
## Alternative Solutions
These were also briefly considered
* Change kernel to not coalesce mmap regions. * Change kernel reporting of coalesced mmap regions to perf. Only include newly mapped memory. * Only strip parts of // anon mmap events overlapping existing jitted-<pid>-<code_index>.so mmap events.
| |