From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
To: Tom Zanussi <tzanussi@gmail.com>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu, fweisbec@gmail.com,
rostedt@goodmis.org
Subject: Re: [RFC][PATCH 2/2] perf: add perf-inject builtin
Date: Sat, 1 May 2010 18:55:55 -0300 [thread overview]
Message-ID: <20100501215555.GE24935@ghostprotocols.net> (raw)
In-Reply-To: <1272696080-16435-3-git-send-email-tzanussi@gmail.com>
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
prev parent reply other threads:[~2010-05-01 22:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-01 6:41 [RFC][PATCH 0/2] perf/live buildid Tom Zanussi
2010-05-01 6:41 ` [RFC][PATCH 1/2] perf/live: don't synthesize build ids at the end of a live mode trace Tom Zanussi
2010-05-01 6:41 ` [RFC][PATCH 2/2] perf: add perf-inject builtin Tom Zanussi
2010-05-01 21:55 ` Arnaldo Carvalho de Melo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100501215555.GE24935@ghostprotocols.net \
--to=acme@ghostprotocols.net \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=tzanussi@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox