Messages in this thread | | | Date | Thu, 12 Mar 2015 11:02:44 +0200 | From | Adrian Hunter <> | Subject | Re: [BUG] perf report: ordered events and flushing bug |
| |
On 12/03/15 05:32, Stephane Eranian wrote: > Hi, > > I am working on the JIT support to improve the flow and have > perf record inject the MMAPs at the end of the collection. For > that I piggyback on the buildid pass. To avoid rewriting the entire perf.data > file, I simply append the the MMAP records at the end of the file. And that > puts them out-of-order in time systematically. But I thought it would be okay > because perf report would sort them by timestamps again. > > Well, it does not in all cases! Why? > > Because of the round flushing. Based on how far out-of-order an event is, > it may not be processed correctly because of round flushing. I believe this > may only impact MMAP records. This is a serious issue because > mmaps drive symbolization of samples. If samples are processed without the > proper dso mapping, then samples may not be symbolized or may be wrongly > symbolized. > > So far, the workaround I found was to set the oe->next_flush = 0 for > the ROUND mode. > In other words, do not flush anything until FINAL. To me, this is the > only sensible > way of avoiding this kind of problems. I am not sure I understand the > point of flushing > anyway, except to minimize memory footprint, maybe. But it does not > work with vastly > out-of-order mmaps. > > Do you have a better solution?
You could hook the ordered event delivery (see Arnaldo's perf/core branch):
if (tool->ordered_events) { inject->deliver = session->ordered_events.deliver; session->ordered_events.deliver = jit_mmap_deliver; }
int jit_mmap_deliver(struct ordered_events *oe, struct ordered_event *event, struct perf_sample *sample) { struct perf_inject *inject = container_of(oe->tool, struct perf_inject, tool);
if (next_jit_mmap_time < sample->time) { <synth mmap event> perf_session__deliver_synth_event(...); } return inject->deliver(oe, event, sample); }
Need to get Arnaldo's comment on this approach first though.
| |