All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Luigi Semenzato <semenzato@chromium.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
	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@suse.de>,
	"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: bug fix: distinguish between rename and exec
Date: Wed, 15 Feb 2012 13:48:33 +0100	[thread overview]
Message-ID: <1329310113.2293.72.camel@twins> (raw)
In-Reply-To: <1329195360-10699-1-git-send-email-semenzato@chromium.org>

On Mon, 2012-02-13 at 20:56 -0800, Luigi Semenzato wrote:
> This makes it possible for "perf report" to distinguish between an exec and
> a rename (for instance from prctl(PR_SET_NAME)).  Currently a similar COMM
> record is produced for the two events.  Perf report assumes all COMM records
> are execs and discards the old mappings.  Without mappings, perf report
> can no longer correlate sampled IPs to the functions containing them,
> and collapses all samples into a single bucket.
> 
> This change maintains backward compatibility in both directions, i.e. old
> version of perf will continue to work on new perf.data files in the same
> way, and new versions of perf on old data files.
> 
> Another solution would be to not send COMM records for renames.  Although
> it seems reasonable, it might break existing setups.

Uhm, didn't you argue its already broken?

> +++ b/fs/exec.c
> @@ -1052,7 +1052,7 @@ char *get_task_comm(char *buf, struct task_struct *tsk)
>  }
>  EXPORT_SYMBOL_GPL(get_task_comm);
>  
> -void set_task_comm(struct task_struct *tsk, char *buf)
> +void set_task_comm(struct task_struct *tsk, char *buf, bool is_rename)
>  {
>  	task_lock(tsk);
>  
> @@ -1068,7 +1068,7 @@ void set_task_comm(struct task_struct *tsk, char *buf)
>  	wmb();
>  	strlcpy(tsk->comm, buf, sizeof(tsk->comm));
>  	task_unlock(tsk);
> -	perf_event_comm(tsk);
> +	perf_event_comm(tsk, is_rename);
>  }

I really dislike changing generic code purely for the purpose of
instrumentation like this. Better to pull perf_event_comm() out of here
if you want to change semantics.

Personally I couldn't care less about renames, I think they're a waste
of time, so I'm ok with the simple patch moving the perf_event_comm()
into setup_new_exec() and possibly renaming it to perf_event_exec().

Acme, do you care about renames?


  reply	other threads:[~2012-02-15 12:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-14  4:56 [PATCH] Perf: bug fix: distinguish between rename and exec Luigi Semenzato
2012-02-15 12:48 ` Peter Zijlstra [this message]
2012-02-15 13:47   ` Arnaldo Carvalho de Melo
2012-02-15 17:07     ` Luigi Semenzato
2012-02-15 17:47       ` Arnaldo Carvalho de Melo
2012-03-02 13:44         ` Stephane Eranian
2012-03-02 14:47           ` Arnaldo Carvalho de Melo
2012-03-02 15:25             ` Stephane Eranian
2012-02-15 16:57   ` David Ahern
2012-02-15 17:22     ` Luigi Semenzato
2012-02-15 17:30       ` David Ahern
2012-02-15 17:30     ` Peter Zijlstra
2012-02-15 18:55       ` David Ahern
     [not found]   ` <CABPqkBTJHOsSfMBMW17reBObLW0bphWZo4AjVh_hTkv5tBHtDA@mail.gmail.com>
2012-02-15 18:07     ` Arnaldo Carvalho de Melo

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=1329310113.2293.72.camel@twins \
    --to=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@suse.de \
    --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.