On 19/08/2015 5:29 p.m., Adrian Hunter wrote:
After recording, 'perf record' post-processes the data to
determine which buildids are needed. That processing must
process the data in time order, if possible, because
otherwise dependent events, like forks and mmaps, will
not make sense.
Signed-off-by: Adrian Hunter <adrian.hun...@intel.com>
---
tools/perf/builtin-record.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index de165a1b9240..f36b88938499 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -500,6 +500,15 @@ static int __cmd_record(struct record *rec, int argc,
const char **argv)
return -1;
}
+ /*
+ * Normally perf_session__new would do this, but it doesn't have the
+ * evlist.
+ */
+ if (rec->tool.ordered_events &&
!perf_evlist__sample_id_all(rec->evlist)) {
+ dump_printf("WARNING: No sample_id_all support, falling back to
unordered processing\n");
+ rec->tool.ordered_events = false;
+ }
+
In fact this chunk is misplaced, it needs to be below the call to record__open()
after which the attributes are correctly configured. And dump_printf() is no
good
for 'perf record', pr_debug would be better. Don't have time to do that right
now,
I'll do it tommorow unless Arnaldo fixes it up.
fd = perf_data_file__fd(file);
rec->session = session;
@@ -965,9 +974,11 @@ static struct record record = {
.tool = {
.sample = process_sample_event,
.fork = perf_event__process_fork,
+ .exit = perf_event__process_exit,
.comm = perf_event__process_comm,
.mmap = perf_event__process_mmap,
.mmap2 = perf_event__process_mmap2,
+ .ordered_events = true,
},
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/