All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>, Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux-mm <linux-mm@kvack.org>, Andi Kleen <andi@firstfloor.org>,
	Christoph Hellwig <hch@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Roland McGrath <roland@hack.frob.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Arnaldo Carvalho de Melo <acme@infradead.org>,
	Anton Arapov <anton@redhat.com>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	Jim Keniston <jkenisto@linux.vnet.ibm.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	yrl.pp-manager.tt@hitachi.com
Subject: Re: [PATCH v8 3.2.0-rc5 9/9] perf: perf interface for uprobes
Date: Fri, 13 Jan 2012 10:44:48 +0530	[thread overview]
Message-ID: <20120113051447.GD10189@linux.vnet.ibm.com> (raw)
In-Reply-To: <4F0F8F41.3060806@hitachi.com>

> 
> I mean that tp->module always !NULL if uprobe, then, we don't need
> to change the code. (thus we can reduce the patch size :))
> 

Agree, the new patch that I sent does this.

> 
> >>> +
> >>> +#define DEFAULT_FUNC_FILTER "!_*"
> >>
> >> This is a hidden rule for users ... please remove it.
> >> (or, is there any reason why we need to have it?)
> >>
> >
> > This is to be in sync with your commit
> > 3c42258c9a4db70133fa6946a275b62a16792bb5
> 
> I see, but that commit also provides filter option for changing
> the function filter. Here, user can not change the filter rule.
> 
> I think, currently, we don't need to filter any function by name
> here, since the user obviously intends to probe given function :)

Actually this was discussed in LKML here
https://lkml.org/lkml/2010/7/20/5, please refer the sub-thread.

Basically without this filter, the list of functions is too large
including labels, weak, and local binding function which arent traced.

We can make this filter settable at a later point of time.

> >
> > If the user provides a symbolic link, convert_name_to_addr would get the
> > target executable for the given executable. This would handy if we were
> > to compare existing probes registered on the same application using a
> > different name (symbolic links). Since you seem to like that we register
> > with the name the user has provided, I will just feed address here.
> 
> Hmm, why do we need to compare the probe points? Of course, event-name
> conflict should be solved, but I think it is acceptable that user puts
> several probes on the same exec:vaddr. Since different users may want
> to use it concurrently bit different ways.
> 

The event-names themselves are generated from the probe points. There is
no problem as such if two or more people use a different symlinks to
create probes. I was just trying to see if we could solve the
inconsitency where we warn a person if he is trying to place a probe on
a existing probe but allow the same if he is trying to place a probe on
a existing probe using a different symlink.

This again I have changed as you suggested in the latest patches that I
sent this week.

-- 
Thanks and Regards
Srikar

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>, Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux-mm <linux-mm@kvack.org>, Andi Kleen <andi@firstfloor.org>,
	Christoph Hellwig <hch@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Roland McGrath <roland@hack.frob.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Arnaldo Carvalho de Melo <acme@infradead.org>,
	Anton Arapov <anton@redhat.com>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	Jim Keniston <jkenisto@linux.vnet.ibm.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	yrl.pp-manager.tt@hitachi.com
Subject: Re: [PATCH v8 3.2.0-rc5 9/9] perf: perf interface for uprobes
Date: Fri, 13 Jan 2012 10:44:48 +0530	[thread overview]
Message-ID: <20120113051447.GD10189@linux.vnet.ibm.com> (raw)
In-Reply-To: <4F0F8F41.3060806@hitachi.com>

> 
> I mean that tp->module always !NULL if uprobe, then, we don't need
> to change the code. (thus we can reduce the patch size :))
> 

Agree, the new patch that I sent does this.

> 
> >>> +
> >>> +#define DEFAULT_FUNC_FILTER "!_*"
> >>
> >> This is a hidden rule for users ... please remove it.
> >> (or, is there any reason why we need to have it?)
> >>
> >
> > This is to be in sync with your commit
> > 3c42258c9a4db70133fa6946a275b62a16792bb5
> 
> I see, but that commit also provides filter option for changing
> the function filter. Here, user can not change the filter rule.
> 
> I think, currently, we don't need to filter any function by name
> here, since the user obviously intends to probe given function :)

Actually this was discussed in LKML here
https://lkml.org/lkml/2010/7/20/5, please refer the sub-thread.

Basically without this filter, the list of functions is too large
including labels, weak, and local binding function which arent traced.

We can make this filter settable at a later point of time.

> >
> > If the user provides a symbolic link, convert_name_to_addr would get the
> > target executable for the given executable. This would handy if we were
> > to compare existing probes registered on the same application using a
> > different name (symbolic links). Since you seem to like that we register
> > with the name the user has provided, I will just feed address here.
> 
> Hmm, why do we need to compare the probe points? Of course, event-name
> conflict should be solved, but I think it is acceptable that user puts
> several probes on the same exec:vaddr. Since different users may want
> to use it concurrently bit different ways.
> 

The event-names themselves are generated from the probe points. There is
no problem as such if two or more people use a different symlinks to
create probes. I was just trying to see if we could solve the
inconsitency where we warn a person if he is trying to place a probe on
a existing probe but allow the same if he is trying to place a probe on
a existing probe using a different symlink.

This again I have changed as you suggested in the latest patches that I
sent this week.

-- 
Thanks and Regards
Srikar


  reply	other threads:[~2012-01-13  5:23 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-16 12:27 [PATCH v8 3.2.0-rc5 0/9] uprobes patchset Srikar Dronamraju
2011-12-16 12:27 ` Srikar Dronamraju
2011-12-16 12:28 ` [PATCH v8 3.2.0-rc5 1/9] uprobes: Install and remove breakpoints Srikar Dronamraju
2011-12-16 12:28   ` Srikar Dronamraju
2012-01-04 16:49   ` Peter Zijlstra
2012-01-04 16:49     ` Peter Zijlstra
2012-01-06  6:14     ` Srikar Dronamraju
2012-01-06  6:14       ` Srikar Dronamraju
2012-01-06 10:57       ` Peter Zijlstra
2012-01-06 10:57         ` Peter Zijlstra
2012-01-06 11:08         ` Srikar Dronamraju
2012-01-06 11:08           ` Srikar Dronamraju
2012-01-04 16:51   ` Peter Zijlstra
2012-01-04 16:51     ` Peter Zijlstra
2012-01-04 17:12     ` Steven Rostedt
2012-01-04 17:12       ` Steven Rostedt
2011-12-16 12:28 ` [PATCH v8 3.2.0-rc5 2/9] uprobes: handle breakpoint and signal step exception Srikar Dronamraju
2011-12-16 12:28   ` Srikar Dronamraju
2011-12-16 12:28 ` [PATCH v8 3.2.0-rc5 3/9] uprobes: slot allocation Srikar Dronamraju
2011-12-16 12:28   ` Srikar Dronamraju
2011-12-16 12:28 ` [PATCH v8 3.2.0-rc5 4/9] uprobes: counter to optimize probe hits Srikar Dronamraju
2011-12-16 12:28   ` Srikar Dronamraju
2011-12-16 12:28 ` [PATCH v8 3.2.0-rc5 5/9] tracing: modify is_delete, is_return from ints to bool Srikar Dronamraju
2011-12-16 12:28   ` Srikar Dronamraju
2011-12-16 12:29 ` [PATCH v8 3.2.0-rc5 6/9] tracing: Extract out common code for kprobes/uprobes traceevents Srikar Dronamraju
2011-12-16 12:29   ` Srikar Dronamraju
2011-12-16 12:29 ` [PATCH v8 3.2.0-rc5 7/9] tracing: uprobes trace_event interface Srikar Dronamraju
2011-12-16 12:29   ` Srikar Dronamraju
2011-12-16 12:29 ` [PATCH v8 3.2.0-rc5 8/9] perf: rename target_module to target Srikar Dronamraju
2011-12-16 12:29   ` Srikar Dronamraju
2011-12-16 12:29 ` [PATCH v8 3.2.0-rc5 9/9] perf: perf interface for uprobes Srikar Dronamraju
2011-12-16 12:29   ` Srikar Dronamraju
2012-01-06 10:51   ` Masami Hiramatsu
2012-01-06 10:51     ` Masami Hiramatsu
2012-01-09 11:22     ` Srikar Dronamraju
2012-01-09 11:22       ` Srikar Dronamraju
2012-01-13  1:56       ` Masami Hiramatsu
2012-01-13  1:56         ` Masami Hiramatsu
2012-01-13  5:14         ` Srikar Dronamraju [this message]
2012-01-13  5:14           ` Srikar Dronamraju
2012-01-13 14:02           ` Masami Hiramatsu
2012-01-13 14:02             ` Masami Hiramatsu
2012-01-16 14:21             ` [PATCH v9 3.2 " Srikar Dronamraju
2012-01-16 14:21               ` Srikar Dronamraju
2012-01-09 11:24     ` [PATCH v8 3.2.0-rc5 " Srikar Dronamraju
2012-01-09 11:24       ` Srikar Dronamraju
2012-01-12 14:50       ` Masami Hiramatsu
2012-01-12 14:50         ` Masami Hiramatsu

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=20120113051447.GD10189@linux.vnet.ibm.com \
    --to=srikar@linux.vnet.ibm.com \
    --cc=acme@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=ananth@in.ibm.com \
    --cc=andi@firstfloor.org \
    --cc=anton@redhat.com \
    --cc=hch@infradead.org \
    --cc=jkenisto@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mingo@elte.hu \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=roland@hack.frob.com \
    --cc=rostedt@goodmis.org \
    --cc=sfr@canb.auug.org.au \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=yrl.pp-manager.tt@hitachi.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 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.