From: Namhyung Kim <namhyung.kim@lge.com>
To: Luigi Semenzato <semenzato@chromium.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Paul Mackerras <paulus@samba.org>, Ingo Molnar <mingo@elte.hu>,
Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
Andrew Morton <akpm@linux-foundation.org>,
Vasiliy Kulikov <segoon@openwall.com>,
Stephen Wilson <wilsons@start.ca>,
Oleg Nesterov <oleg@redhat.com>, Tejun Heo <tj@kernel.org>,
Paul Gortmaker <paul.gortmaker@windriver.com>,
Andi Kleen <ak@linux.intel.com>,
Lucas De Marchi <lucas.demarchi@profusion.mobi>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
Frederic Weisbecker <fweisbec@gmail.com>,
David Ahern <dsahern@gmail.com>,
Namhyung Kim <namhyung@gmail.com>,
Robert Richter <robert.richter@amd.com>,
linux-kernel@vger.kernel.org, sonnyrao@chromium.org,
olofj@chromium.org, eranian@google.com
Subject: Re: [PATCH] perf: add PERF_RECORD_EXEC type, to distinguish from PERF_RECORD_COMM (DO NOT APPLY)
Date: Mon, 05 Mar 2012 11:04:16 +0900 [thread overview]
Message-ID: <4F541F20.7000405@lge.com> (raw)
In-Reply-To: <1330716607-28227-1-git-send-email-semenzato@chromium.org>
Hi, again.
2012-03-03 4:30 AM, Luigi Semenzato wrote:
> ---- NOT FINISHED - NOT TESTED ---- rfc only
>
> I agree with others that adding a new record type is the cleanest solution.
> This is more or less what it takes to add a new record type. It may be
> more than we like but that's a separate problem. I am open to other
> solutions. I may be able to do a bit of refactoring to reduce the
> copy-paste, but of course the CL will grow as the refactoring would
> not be limited to COMM and EXEC.
>
> ---- actual commit message below ----
>
> Currently the kernel produces a PERF_RECORD_COMM type record both when
> a process execs and when it renames its "comm" name. The "perf report"
> command interprets each COMM record as an exec, and flushes all
> mappings to executables when it encounters one. This can result in the
> inability to correlate IP samples to function symbols.
>
> This CL adds a PERF_RECORD_EXEC type, which doesn't contain the process
> name (the comm field). Thus, an exec now must send two records, one EXEC
> and one COMM, whereas a rename sends only a COMM.
>
> The change is mostly straightforward, but there are some complications
> in the synthesized events sent when "perf record" starts to account for
> existing processes.
>
> Signed-off-by: Luigi Semenzato<semenzato@chromium.org>
> ---
> fs/exec.c | 1 +
> include/linux/perf_event.h | 19 +++++-
> kernel/events/core.c | 153 +++++++++++++++++++++++++++++++++++++++++---
> tools/perf/builtin-test.c | 24 ++-----
> tools/perf/builtin-top.c | 5 +-
> tools/perf/util/event.c | 148 +++++++++++++++++++++++++++++-------------
> tools/perf/util/event.h | 11 +++
> tools/perf/util/evsel.c | 5 +-
> tools/perf/util/python.c | 42 +++++++++++-
> tools/perf/util/session.c | 11 +++
> tools/perf/util/thread.c | 1 -
> tools/perf/util/tool.h | 1 +
> 12 files changed, 338 insertions(+), 83 deletions(-)
>
> diff --git a/fs/exec.c b/fs/exec.c
> index e33501a..077d199 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -1144,6 +1144,7 @@ void setup_new_exec(struct linux_binprm * bprm)
> else
> set_dumpable(current->mm, suid_dumpable);
>
> + perf_event_exec(current);
> set_task_comm(current, bprm->tcomm);
>
> /* Set the new mm task size. We have to do that late because it may
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index 64426b7..8e4a472 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -200,8 +200,8 @@ struct perf_event_attr {
> exclude_kernel : 1, /* ditto kernel */
> exclude_hv : 1, /* ditto hypervisor */
> exclude_idle : 1, /* don't count when idle */
> - mmap : 1, /* include mmap data */
> - comm : 1, /* include comm data */
> + mmap_attr : 1, /* include mmap data */
> + comm_attr : 1, /* include comm data */
> freq : 1, /* use freq, not period */
> inherit_stat : 1, /* per task counts */
> enable_on_exec : 1, /* next exec enables */
> @@ -223,8 +223,10 @@ struct perf_event_attr {
>
> exclude_host : 1, /* don't count in host */
> exclude_guest : 1, /* don't count in guest */
> + /* COMM used to mean exec in older versions */
> + exec_attr : 1, /* include exec data */
>
> - __reserved_1 : 43;
> + __reserved_1 : 42;
>
This new bit will cause the same issue with ->sample_id_all and
->exclude_{host,guest} on old kernels. It needs to be handled too in a similar
way of perf record/top IMHO.
Thanks,
Namhyung
prev parent reply other threads:[~2012-03-05 2:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-02 19:30 [PATCH] perf: add PERF_RECORD_EXEC type, to distinguish from PERF_RECORD_COMM (DO NOT APPLY) Luigi Semenzato
2012-03-05 1:16 ` Namhyung Kim
2012-03-05 2:04 ` Namhyung Kim [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=4F541F20.7000405@lge.com \
--to=namhyung.kim@lge.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@ghostprotocols.net \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=dsahern@gmail.com \
--cc=ebiederm@xmission.com \
--cc=eranian@google.com \
--cc=fweisbec@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lucas.demarchi@profusion.mobi \
--cc=mingo@elte.hu \
--cc=namhyung@gmail.com \
--cc=oleg@redhat.com \
--cc=olofj@chromium.org \
--cc=paul.gortmaker@windriver.com \
--cc=paulus@samba.org \
--cc=rjw@sisk.pl \
--cc=robert.richter@amd.com \
--cc=segoon@openwall.com \
--cc=semenzato@chromium.org \
--cc=sonnyrao@chromium.org \
--cc=tj@kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=wilsons@start.ca \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.