public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Masami Hiramatsu <mhiramat@redhat.com>,
	Mel Gorman <mel@csn.ul.ie>,
	Jim Keniston <jkenisto@linux.vnet.ibm.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	"Frank Ch. Eigler" <fche@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Roland McGrath <roland@redhat.com>,
	Oleg Nesterov <oleg@redhat.com>,
	Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH v1 7/10] Uprobes Implementation
Date: Wed, 24 Mar 2010 11:29:39 +0530	[thread overview]
Message-ID: <20100324055939.GA21999@in.ibm.com> (raw)
In-Reply-To: <1269357354.5109.83.camel@twins>

On Tue, Mar 23, 2010 at 04:15:54PM +0100, Peter Zijlstra wrote:
> On Tue, 2010-03-23 at 20:35 +0530, Ananth N Mavinakayanahalli wrote:
> > Now the question is, where the complexity needs to be.
> 
> Both in-tree consumers of uprobes (ftrace and perf) are capable of task
> filters.
> 
> But the thing is, dso:sym is very much not a task property, adding task
> filters afterwards sure makes sense in some cases but it should not be
> the primary mode.

Not sure if I am following you correctly...

> If people really want to optimize this we can easily add a few bits of
> task state which could tell the trap handler to not even bother looking
> up things but restart as fast as possible.

Are you suggesting we have the global tracing as default and
then have task filters. I've already alluded to this being vetoed
earlier, by people including Andrew Morton, Hugh Dickins, Arjan,
Christoph Hellwig, Nick Piggin, etc. It's a route we'd prefer not to
go down again...

Aside, what are the mechanisms to do this?

The current breakpoint insertion and removal, even for shared libraries,
is process local since the only page tables of the process being traced
is modified.

In order to have a global visibility of dso probes, one obvious method
is to put in the probes before the text hits pagecache. This approach
works for 'yet-to-start' processes that would map the dso too. This was
prototyped in the series at http://lkml.org/lkml/2006/5/9/25 did that
and was suitably junked, for very valid reasons. Even Hugh Dickins
thumbed down the pagecache approach (http://lkml.org/lkml/2006/5/9/209)

Given the current design has enough flexibility to accommodate non perf
users like gdb, a simple pid based approach for the lowest layer makes
the most sense. I'd rather prefer a higher level entity (say, perf) do
the difficult job of filtering down individual requests only for
processes of interest, then the lower layer can iteratively do the probe
insertions for all processes of interest.

I am not sure if there is a better method to do probes with 'global'
visibility. Did you have an easier approach in mind?

Ananth

  parent reply	other threads:[~2010-03-24  5:59 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-20 14:24 [PATCH v1 0/10] Uprobes patches Srikar Dronamraju
2010-03-20 14:25 ` [PATCH v1 1/10] Move Macro W to insn.h Srikar Dronamraju
2010-03-20 15:50   ` Masami Hiramatsu
2010-03-22  6:24     ` Srikar Dronamraju
2010-03-22 14:11       ` Masami Hiramatsu
2010-03-20 14:25 ` [PATCH v1 2/10] Move replace_page() to mm/memory.c Srikar Dronamraju
2010-03-20 14:25 ` [PATCH v1 3/10] Enhance replace_page() to support pagecache Srikar Dronamraju
2010-03-20 14:25 ` [PATCH v1 4/10] User Space Breakpoint Assistance Layer Srikar Dronamraju
2010-03-23  1:40   ` Andrew Morton
2010-03-23  4:48     ` Randy Dunlap
2010-03-23 11:26     ` Srikar Dronamraju
2010-03-20 14:25 ` [PATCH v1 5/10] X86 details for user space breakpoint assistance Srikar Dronamraju
2010-03-20 14:26 ` [PATCH v1 6/10] Slot allocation for Execution out of line Srikar Dronamraju
2010-03-20 14:26 ` [PATCH v1 7/10] Uprobes Implementation Srikar Dronamraju
2010-03-23 11:01   ` Peter Zijlstra
2010-03-23 11:04     ` Peter Zijlstra
2010-03-23 12:23     ` Srikar Dronamraju
2010-03-23 13:46       ` Peter Zijlstra
2010-03-23 14:20         ` Masami Hiramatsu
2010-03-23 15:15           ` Peter Zijlstra
2010-03-23 17:36             ` Masami Hiramatsu
2010-03-24 10:22           ` Srikar Dronamraju
2010-03-23 15:05         ` Ananth N Mavinakayanahalli
2010-03-23 15:15           ` Peter Zijlstra
2010-03-23 15:26             ` Frank Ch. Eigler
2010-03-24  5:59             ` Ananth N Mavinakayanahalli [this message]
2010-03-24  7:58         ` Srikar Dronamraju
2010-03-24 13:00           ` Peter Zijlstra
2010-03-25  7:56             ` Srikar Dronamraju
2010-03-25  8:41             ` Srikar Dronamraju
2010-03-20 14:26 ` [PATCH v1 8/10] X86 details for uprobes Srikar Dronamraju
2010-03-20 14:26 ` [PATCH v1 9/10] Uprobes Documentation patch Srikar Dronamraju
2010-03-22  3:00   ` Randy Dunlap
2010-03-22  5:34     ` Srikar Dronamraju
2010-03-22 14:51       ` Randy Dunlap
2010-03-20 14:26 ` [PATCH v1 10/10] Uprobes samples Srikar Dronamraju
2010-03-23  1:38 ` [PATCH v1 0/10] Uprobes patches Andrew Morton
2010-03-23 10:55   ` Srikar Dronamraju

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=20100324055939.GA21999@in.ibm.com \
    --to=ananth@in.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=fche@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=hch@infradead.org \
    --cc=jkenisto@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mel@csn.ul.ie \
    --cc=mhiramat@redhat.com \
    --cc=mingo@elte.hu \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=roland@redhat.com \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=torvalds@linux-foundation.org \
    /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