[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150922000452.GA5902@sejong>
Date: Tue, 22 Sep 2015 09:04:52 +0900
From: Namhyung Kim <namhyung@...nel.org>
To: Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: Ingo Molnar <mingo@...nel.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Jiri Olsa <jolsa@...hat.com>,
LKML <linux-kernel@...r.kernel.org>,
David Ahern <dsahern@...il.com>
Subject: Re: [PATCH 2/2] perf record: Synthesize COMM event for a command
line workload
Hi Arnaldo,
On Mon, Sep 21, 2015 at 04:39:26PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Sep 21, 2015 at 09:26:49AM +0900, Namhyung Kim escreveu:
> > When perf creates a new child to profile, the events are enabled on
> > exec(). And in this case, it doesn't synthesize any event for the
> > child since they'll be generated during exec(). But there's an window
> > between the enabling and the event generation.
> >
> > It used to be overcome since samples are only in kernel (so we always
> > have the map) and the comm is overridden by a later COMM event.
> > However it won't work if events are processed and displayed before the
> > COMM event overrides like in 'perf script'. This leads to those early
> > samples (like native_write_msr_safe) not having a comm but pid (like
> > ':15328').
> >
> > So it needs to synthesize COMM event for the child explicitly before
> > enabling so that it can have a correct comm. But at this time, the
> > comm will be "perf" since it's not exec-ed yet.
> >
> > Acked-by: Jiri Olsa <jolsa@...hat.com>
> > Signed-off-by: Namhyung Kim <namhyung@...nel.org>
> > ---
> > tools/perf/builtin-record.c | 41 ++++++++++++++++++++++++++++++++++++++++-
> > 1 file changed, 40 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> > index 142eeb341b29..b83373adb9f8 100644
> > --- a/tools/perf/builtin-record.c
> > +++ b/tools/perf/builtin-record.c
> > @@ -469,6 +469,43 @@ static void workload_exec_failed_signal(int signo __maybe_unused,
> > child_finished = 1;
> > }
> >
> > +static int synthesize_workload_comm_event(struct perf_evlist *evlist, void *arg)
> > +{
> > + union perf_event *event;
> > + struct record *rec = arg;
> > + struct machine *machine = &rec->session->machines.host;
> > + int pid = evlist->workload.pid;
> > + const char *comm_str = program_invocation_short_name;
> > + size_t comm_size, total_size;
> > + int ret;
> > +
> > + comm_size = PERF_ALIGN(strlen(comm_str) + 1, sizeof(u64));
> > + total_size = sizeof(event->comm) + machine->id_hdr_size;
> > + /*
> > + * (aligned) comm size might be smaller than expected size
> > + * (i.e. size of event->comm.comm[]), in that case it needs
> > + * to shrink the total size.
> > + */
> > + if (comm_size < sizeof(event->comm.comm))
> > + total_size -= sizeof(event->comm.comm) - comm_size;
> > +
> > + event = zalloc(total_size);
> > + if (event == NULL)
> > + return -ENOMEM;
> > +
> > + event->comm.header.type = PERF_RECORD_COMM;
> > + event->comm.header.size = total_size;
> > +
> > + event->comm.pid = pid;
> > + event->comm.tid = pid;
> > + strncpy(event->comm.comm, comm_str, comm_size);
> > +
> > + ret = record__write(rec, event, total_size);
> > +
> > + free(event);
> > + return ret;
> > +}
> > +
> > static void snapshot_sig_handler(int sig);
> >
> > static int __cmd_record(struct record *rec, int argc, const char **argv)
> > @@ -637,7 +674,9 @@ static int __cmd_record(struct record *rec, int argc, const char **argv)
> > * Let the child rip
> > */
> > if (forks)
> > - perf_evlist__start_workload(rec->evlist);
> > + perf_evlist__start_workload_ex(rec->evlist,
> > + synthesize_workload_comm_event,
> > + rec);
>
> Why not call it directly? I.e.:
>
> if (forks) {
> err = synthesize_workload_comm_event(evlist, rec);
> if (!err)
> err = perf_evlist__start_workload(rec->evlist);
> }
>
> Since, from what I saw, the very first thing that
> perf_evlist__start_workload_ex() does is to call the callback?
I originally thought that it'd be used by other commands too. I
checked that 'perf trace' has similar code so I generalized it with
callbacks. But then I realized the perf trace generates events only
after exec() so I dropped the patch for it.
>
> Also, don't we have already a synthesize_comm routine? I.e. can't
> perf_event__prepare_comm() be used here?
Ok, it'd be better exporting perf_event__synthesize_comm() for
consistency then. Will send v2 soon.
Thanks,
Namhyung
--
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