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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®