Re: [PATCHv11 2.6.36-rc2-tip 5/15] 5: uprobes: Uprobes (un)registration and exception handling.

[Peter Zijlstra <peterz@infradead.org>]

On Mon, 2010-09-06 at 23:16 +0530, Srikar Dronamraju wrote:
> * Peter Zijlstra <peterz@infradead.org> [2010-09-03 19:19:09]:
> 
> > > 
> > > However I would have an issue with making inode based probing the
> > > default.
> > > 1. Making all probing based on inode can be a performance hog.
> > 
> > How so? You can add filters if you want.
> 
> The breakpoint exception and singlestep account for a substaintial
> time
> of the uprobes probe handling. With increasing number of breakpoint
> hits and singlesteps, wouldnt the overall load increase?
> 
You're really not getting it, are you? No, it would result in the exact
same amount of actual breakpoints hit.

> > 
> > > 2. Since unlike kernel space, every process has a different space, so
> > > why would we have to insert breakpoints in each of its process space if
> > > we are not interested in them.
> > 
> > You don't have to, but you can. The problem I have with this stuff is
> > that it makes the pid thing a primary interface, whereas it should be
> > one of many filter possibilities.
> 
> I think the otherway, 
> Why instrument a process and filter it out, if we are not interested in it.
> While instrumenting kernel, we dont have this flexibility. So
> having a pid based filter is the right thing to do for kernel
> based tracing.
> 
> If we can get the per process based tracing right, we can build
> higher lever stuff including the file based tracing easily.

Creating inode based probes on top of pid based probes is terribly ugly.

>  Just to clarify, I am not looking at probing per task
> but probing per process. So the pid field in uprobe refers to the
> tgid. 

Urgh,.. I really oppose the whole pid-centric thing, if that means
process wide and not per task its even worse.