On 3/2/2018 6:30 PM, Jiri Olsa wrote:
On Thu, Mar 01, 2018 at 06:08:59PM -0500, kan.li...@linux.intel.com wrote:
From: Kan Liang <kan.li...@linux.intel.com>
The perf trace still use the legacy interface.
Apply the new perf_mmap__read_event() interface for perf trace.
No functional change.
Signed-off-by: Kan Liang <kan.li...@linux.intel.com>
---
tools/perf/builtin-trace.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index e7f1b18..a46644f 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -2472,8 +2472,14 @@ static int trace__run(struct trace *trace, int argc,
const char **argv)
for (i = 0; i < evlist->nr_mmaps; i++) {
union perf_event *event;
+ struct perf_mmap *md;
+ u64 end, start;
- while ((event = perf_evlist__mmap_read(evlist, i)) != NULL) {
+ md = &evlist->mmap[i];
+ if (perf_mmap__read_init(md, 0, &start, &end) < 0)
+ continue;
should we break the loop if this returns -EINVAL?
It only means the ring buffer is broken for current mmaps.
For others, the data should still be good.
I don't think we should drop them by breaking the loop.
Also, the -EINVAL is only valid for overwrite mode. It is impossible to
return -EINVAL in current code.
Thanks,
Kan
jirka
+
+ while ((event = perf_mmap__read_event(md, 0, &start, end)) !=
NULL) {
struct perf_sample sample;
++trace->nr_events;
@@ -2486,7 +2492,7 @@ static int trace__run(struct trace *trace, int argc,
const char **argv)
trace__handle_event(trace, event, &sample);
next_event:
- perf_evlist__mmap_consume(evlist, i);
+ perf_mmap__consume(md, 0);
if (interrupted)
goto out_disable;
@@ -2496,6 +2502,7 @@ static int trace__run(struct trace *trace, int argc,
const char **argv)
draining = true;
}
}
+ perf_mmap__read_done(md);
}
if (trace->nr_events == before) {
--
2.4.11
