Re: [RFC][PATCH 2/2] perf: add perf-inject builtin

From: Arnaldo Carvalho de Melo
Date: Sat May 01 2010 - 18:03:30 EST


Em Sat, May 01, 2010 at 01:41:20AM -0500, Tom Zanussi escreveu:
> Currently, perf 'live mode' writes build-ids at the end of the
> session, which isn't actually useful for processing live mode events.
>
> What would be better would be to have the build-ids sent before any of
> the samples that reference them, which can be done by processing the
> event stream and retrieving the build-ids on the first hit. Doing
> that in perf-record itself, however, is off-limits.
>
> This patch introduces perf-inject, which does the same job while
> leaving perf-record untouched. Normal mode perf still records the
> build-ids at the end of the session as it should, but for live mode,
> perf-inject can be injected in between the record and report steps
> e.g.:
>
> perf record -o - ./hackbench 10 | perf inject -v -b | perf report -v -i -
>
> perf-inject reads a perf-record event stream and repipes it to stdout.
> At any point the processing code can inject other events into the
> event stream - in this case build-ids (-b option) are read and
> injected as needed into the event stream.
>
> Build-ids are just the first user of perf-inject - potentially
> anything that needs userspace processing to augment the trace stream
> with additional information could make use of this facility.

Good work, I'd just make "read_buildid" be "dso__read_buildid", make its
'self' parameter be a struct dso pointer, first check if had its build
id read already, read it if not. Yeah, dsos can change, but that is also
not supported in 'perf record', where we do it at the end.

I.e. reducing the cost of build-id processing even in live mode is also
interesting and OK for the normal case of not changing DSOs while a
session is running.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/