[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABPqkBRYYGnUHPOXfM06yWSkXXNswFLMRNz8kGXJ4MWj9=3OSw@mail.gmail.com>
Date: Wed, 11 Mar 2015 23:32:15 -0400
From: Stephane Eranian <eranian@...gle.com>
To: LKML <linux-kernel@...r.kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@...hat.com>,
Namhyung Kim <namhyung@...nel.org>,
Jiri Olsa <jolsa@...hat.com>, David Ahern <dsahern@...il.com>,
Peter Zijlstra <peterz@...radead.org>,
"mingo@...e.hu" <mingo@...e.hu>
Subject: [BUG] perf report: ordered events and flushing bug
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?
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists